Early Startups: Building a Great SaaS App on a Tight Budget
As a SaaS startup founder, your main objective is to get your big idea realized, your MVP in front of your customers.
This focus on speed-to-market, combined with a tight budget (unless you’re really lucky) makes for a pragmatic, sometimes even opportunistic attitude towards whatever gets you there.
This opportunistic approach to running your startup presents some challenges in building the technical foundations of your SaaS app.
If you’re aware of these dynamics and keep a few things in mind, you can be extremely lean and pragmatic but still make a fantastic first impression with your SaaS MVP.
As a Chief Technology Officer (CTO), I have worked with numerous early startups and have seen many of them struggle with tech.
I’ll group my findings into Process, Product and People:
Process
Being as Lean as possible, you probably don’t need much process tooling at first. No need for expensive project management, CRM or financial tooling, but some structure is still needed: you need some form of knowledge- and task/workflow management.
Knowledge Management
I have found that startups tend to start off with an Office subscription of some kind (Google, Microsoft) because they will obviously need mail, then automatically start using the accompanying storage option (Google Drive, OneDrive) and don’t even think about it.
The collective knowledge that sits in your startup, at any stage, is your gold. But if you can’t quickly surface it, it’s worthless. Equally, if your team doesn’t have immediate access to the same information (“When did you send me that document?”), efficiency is soon lost.
Storing documents in folders is not Knowledge Management
In order to get your team ‘on the same page’, use a Knowledge Management tool, preferably one that makes it ultra-simple and productive to type-and-share anything.
In the days, I would have said ‘use a Wiki’, but compared to some of the (SaaS) tooling that is around today, wikis feel sluggish and cumbersome.
Personally, I’m extremely happy with Nuclino. Nuclino offers a direct and focused view on content, with productivity in mind. Content is live as-you-type, internal cross-linking a breeze and adding images, videos, diagrams is done via copy/paste or drag-and-drop.
There are so many good Knowledge Management tools that allow a team to be (and keep) on the same page with everything that matters in running a startup and developing a strategy.
Using modern Knowledge Management tools however requires a mindset shift: all team members have to lose old habits of sending each other emails with attached documents, write internal documents to then store them in some SharePoint/OneDrive/Google Drive/Dropbox folder that they feel is adequate and share via emailed links.
I’ve been working with so many startups, scaleups and ISVs that admitted their internal knowledge sharing was an absolute nightmare that I can safely say using a proper Knowledge Management system makes a tremendous difference.
Priorities
Being Lean inevitably means continuously making strict decisions on what to do to ultimately get to your product release:
What is important is seldom urgent and what is urgent is seldom important.
-Dwight Eisenhower
“Urgent tasks are things that you feel like you need to react to: emails, phone calls, texts, news stories. Meanwhile, in the words of Brett McKay, “Important tasks are things that contribute to our long-term mission, values, and goals.”
Separating these differences is simple enough to do once, but doing so continually can be tough. The reason I like the Eisenhower Matrix is that it provides a clear framework for making the decisions over and over again. And like anything in life, consistency is the hard part.” — source
Product
Building Value
What I keep saying to every startup and scaleup is: focus on where the value is being built up. Easier said than done, but it’s really not that hard:
Intellectual Property buildup and thinking in terms of an Exit Strategy should be key to decision making in startups and scaleups, in any phase.
It’s really that simple: the question “does this affect IP?” provides an answer whenever stuff needs to be done (or not), built (or bought), etc.
I remember a startup that had one developer working for 6 months on a custom PDF generator tool, for reports that needed to be sent via email.
There are hundreds of PDF Generation SaaS services and Open Source PDF generators that could have done the trick, but this developer either didn’t do his research right or thought he could build a better mousetrap. In either case however, asking the question “does this affect IP?” would have been answered with a simple “No!”.
The effects of stricter IP-based decision making can be dramatic, as this example shows. Imagine what good stuff could have been built in six months!
In short, build-or-buy decisions should always be directly driven by IP thinking.
Architecture
I know I’m not preaching to the choir here, but my advice to young startups has always been to prioritize architecture over implementation.
“If you think good architecture is expensive, try bad architecture” — Brian Foote and Joseph Yoder
I know, I’m coming from the Enterprise Software area, but giving architectural design some initial focus (maybe with some external help) is always a good idea, and will save your startup from quite a bit of pain (and money) later on.
Obviously, given the time-to-market focus, you don’t want to over-architecture anything, but if you want to facilitate your success at launch time, at least take a look at a few architectural aspects:
- Storing data in a secure and compliant way (e.g. GDPR)
- Implement multi-tenancy
- Operational performance and availability
- Extensibility
Measure Everything
In the “Lean” methodology, efficiency is key, as we mentioned before. This essentially means don’t build what’s not needed, and adapt using actual usage data.
This means you’ll have to collect as much data as you can on how users are actually interfacing with your app, even at prototype- or internal beta phase.
There’s a multitude of software platforms that can help with that, with minimal effort, so there’s no excuse not to be data-driven:
- New Relic
- Application Insights (Azure)
- CloudWatch (AWS)
- HotJar
- Inspectlet
- Etc.
Modern Cloud Benefits
As I have stated in previous articles, Cloud has brought about a paradigm shift in thinking about Software Development. Literally every aspect of development has changed for good, especially in Native Cloud:
This means you can still develop your application locally (on premises), deploy it to a Cloud Platform and see it run without massive amount of change needed. You can. Whether you should is an entirely different question.
Cloud Levels
Cloud has come a long way. Simply said, first migrations of on-premises apps to Cloud simply involved putting virtual machines on different hardware (IaaS).
The next step was containerization: smaller independent units of work that could be deployed more easily and abstracted a lot of the OS (CaaS).
Of course, the big Cloud Providers then added all kinds of hosted (or managed) versions of app service layers that made it even easier to deploy just apps and data (PaaS), and the latest addition has been to abstract nearly every aspect of the underlying application, and all aspects of the layers below (FaaS — aka Serverless).
In terms of the aspects of the total solutions that you, as a startup, need to manage, you can look at it this way:
Obviously, the higher the Cloud Level, the less you have to manage yourself. With the Lean hat on, it’s not hard to see that using as much Serverless and PaaS level Cloud as possible, will allow you to focus on your app and data, and avoid having to deal with the technical hassle of scaling out, data backups, fail-over, security patches, OS updates, etc.
Lean Tech
My PDF generator example touched upon the subject already, but looking at all the stuff you have a build vs buy decision to make on, it pays off spending a bit of time on finding out the services or open source/third party libraries that could fulfill a job in your app.
Similarly to the often-heard statement “there’s an app for that”, there’s probably a service/component for that, except maybe for precisely that part which is so core to your intellectual property or USP - which is a good thing ;-).
Find your services using programmableweb.com, apis.io or rapidapi.com, look up libraries and best practices on github.com and nuget.org and if you don’t have all the answers directly, find them on stackoverflow.com.
Bootstrapping
No one builds complex SaaS systems using a blank canvas anymore. There are bootstrappers in nearly every area, from HTML/CSS to Cloud Architecture Patterns. Use them to speed up initial development.
The Mobile Dilemma
I can have long discussions about web and mobile development with people I meet. Depending on their core business, they will either try to convince me that native mobile app development is (and will always be) superior to anything built as a web app and shown on a mobile phone, or they will say that native app development is dying and that the combined evolution of web standards and smartphone capabilities will eventually make native development obsolete.
As a CTO, it’s not per se my own preference that counts. The decision to spawn a separate process to develop a native mobile app has a major impact on startups:
- Extra development resources needed
- More complex feature management
- Slower roll-out
- Added support complexity
In short, I would strongly advise startups against even thinking of an app in the early days, unless the product would have a much better market-fit (e.g. because personas are primarily mobile).
Later on, after some solid funding has been achieved, native mobile apps might be reconsidered, but still all consequences should be taken in consideration. I have seen many scaleups that ended up having a native mobile app that could easily have been developed as a hybrid app (allowing for their web front-end to be embedded in mobile views), suffering from all 4 disadvantages mentioned above.
People
Last but not least, managing the human involvement that is needed to get your product to market is always one of the hardest parts of running a startup.
There is no magic trick, no single best solution that fits all, because it all depends on your setup. Do you just have a commercial idea or are you capable of overseeing most technical aspects yourself? Who’s in it with you? Do you have a tech co-founder? Or any partners/freelancers who are highly loyal or willing to do revenue-sharing? Etc.
Outsourcing
It is extremely easy to get involved with development shops that will take your requirements and turn them into a solution. With some basic selection mechanism, looking at their portfolio, it’s not much harder to at least know the contracting party has decent professional standards, but where things tend to go wrong is in the daily routines. Alignment with your extremely lean, agile, adaptive and data-driven (see under ‘Process’) modus operandi isn’t easy for this kind of outsourced party, which tend to be better equipped for waterfall-type projects than your average agile product development.
Internal Product Owner
A solution to this situation is to hire/assign a Product Owner (PO) locally who will interface with the outsourced team and will act as the translation layer both ways, keeping close to what it is you wish to bring to market, but also rephrase some of the questions the outsourcing party will bring up during the development process.
I have seen many failures in getting outsourcing to work. Chances of success are much higher with a good internal PO.
Assistance on Technical Strategy
At early-startup stage, you have to be extremely lucky if you have someone who has been doing SaaS tech before and who’s been there, done that.
Adding someone with this kind of experience to your payroll is mostly impossible because of the cost involved (unless again, you’re lucky and find someone who’s willing to take shares or revenue sharing — and very low pay).
However, it does pay off to get some actual experience in on SaaS Tech Strategy, even if just for a few hours a week, and even if it’s just to do a bit of technical validation of your plans, evaluating your app in terms of optimal Cloud fit, or assisting in finding development partners.
