Building the first product at a startup
Lessons learned in the first six months at a tech startup. A personal account of what went right and what didn’t.
Most of my career has been at established companies, working on web applications that handle a lot of traffic, in cross-functional teams with about five or six developers, following an agile workflow.
All that changed a two years ago when I accepted the role of CTO at a tech startup and was given the task of building the company’s software platform from scratch. The job title sounds grand, but I was actually the only developer. In fact, I was the only employee — it was just me and the founder.
I’m glad to say that I delivered the platform successfully, the product launched on time, and the company is now focusing its efforts on increasing revenue. In hindsight, I can see what I got right, and also identify a number of things I would do differently next time. I describe them here for anyone who finds themselves in a similar situation: at a startup, faced with building a software product from scratch.
My experience working on high traffic websites meant I knew a thing or two about building a scalable web platform. I knew how to auto-scale clusters of virtual servers and distribute the load between them. I knew how to manage distributed transactions, and I understood the pros and cons of microservices and serverless versus monolithic architectures. I was into monitoring. I did TDD.
Buoyed by the founder’s enthusiasm and excited by his vision of a fully integrated sales and delivery platform, I went in all guns blazing. I knew I could put my experience to use and build a platform that was robust, scalable, and maintainable; one that would support the business for years to come, free of technical debt. I would learn from my and others’ mistakes and create a textbook example of how a web platform should be built.
Turns out I had got ahead of myself.
When we launched, I think it’s fair to say we were disappointed. The hordes of customers that preliminary market research had promised us failed to materialise, and ongoing negotiation with our partners in the supply chain meant that whatever orders we got had to be dealt with manually. I had built an automated order management system designed to handle hundreds of orders per second that looked now something like the software equivalent of a diving suit for walking through puddles.
The reality is a lot of my initial concerns are relevant for bigger scale projects but it’s a waste of effort to incorporate them in stage one. They are valid concerns that every developer needs to have, but the concerns of the business must come first, and frankly, in a two-person startup there is neither the time or budget for anything but the essentials. If we spent too long building we risked falling behind our competitors, but more importantly, it would delay the critical moment when we found out whether the business idea will work. This was important to our investors, and also to me. I had taken a pay cut and wanted assurance that I was not on a hiding to nothing.
Here is my advice with the benefit of hindsight. It’s only based on one person’s experience, in one company, and I don’t promise that it is a foolproof formula for guaranteed success. It’s simply my thoughts on what I would do differently next time.
1. Start small. Really small.
My advice is to keep the first version of the product as simple as possible. Make it look nice, but build it in something like WordPress, or as a few pages of hastily written PHP.
As a developer, you may not be proud of what you have created but go with it. If you are a founder reading this, consider whether you even need a full-time developer at this stage. Instead, you could hire an agency or a contractor to knock something up quickly to get you going.
If the business idea succeeds more investment will come, and if your CEO knows what they are doing they will use some of that investment to rebuild things properly. If the business idea fails, no one will care whether or not the architecture was web scale.
2. Build from the front inwards
If you are building a customer-facing product, build the front-end first. That’s the bit that everyone sees. A back end is needed to support the front end, but really on day one, you might be able to manage with nothing more than an email form.
I did worry that once the front end was done the stakeholders would deign the product complete, and get impatient waiting for the back end work — a black box to them — to be completed. This is a problem you will need to manage and I would advise explaining things clearly to the stakeholders and agreeing to launch with a minimal, or even a manual, back-end process.
3. Build it now, design it later
We had an external design agency with whom we were iterating on the visual elements of the product. This took time as the design evolved through several stages, and the initial design and the final design were very different. I was tempted to hold back coding anything on the front-end until the design had stabilised, as I didn’t want to be continually building and rebuilding, but instead I just pushed ahead and built the front-end without a design.
This meant I was able to get something up and running quickly, which let the designers and the founder experiment and provide early feedback on the product.
I’m glad I did that. It exposed a few problems with the product early. It’s also satisfying to stakeholders to see progress.
Accept that you will have to replace some of what you have made, but be reassured that you will be able to use the knowledge you gain, and possibly even some of the actual code once the design is signed off.
4. Don’t worry about technical debt
Plan to throw one away; you will, anyhow. — Fred Brooks, The Mythical Man Month
During my formative years as a developer, I would mutter under my breath unfavourable remarks about whoever originally wrote the code I was working on: “If only they’d considered internationalisation up front!” “What was this idiot thinking by not writing tests?” “Hardcoded tax rules? WTF!”. I knew that if I ever got the opportunity to build a product from scratch I would be sure to do things properly, and keep technical debt close to zero.
Technical debt is stuff that you really should do but which is not immediately visible to the product owner (CEO). It’s stuff you need in order to retain maintainability, to keep the code clean with nowhere for bugs to hide, to make things nicely scalable, and so on.
This needs to be done, but it has to take second place in the very early stages. Make sure your CEO is well aware that you will need a lot of time, soon, to sort this stuff out before it cripples the company. I once worked for a company that had grown beyond its early startup phase but where the product never had this attention. It was full of bugs and a nightmare to work on. Fixing one bug would introduce another one, and adding simple features would often require rewriting large parts of the code. Developers would pull sickies rather than work on parts of it. The churn in the team was enormous. The company went bust.
In the early stages, nobody has a clear idea of how the product should work, and even if they do, they must be flexible and ready to change the product in light of new information and ideas about the business (see The Lean Startup, by Eric Reis). For this reason, don’t invest too much in writing textbook code at first. As soon as the product does stabilise, that is the time for a big rewrite. Before that though, you are really just building a prototype.
5. Don’t focus too much on Test Driven Development
Try explaining to the CEO why the product isn’t ready yet, when a kid they just met in the pub told them he could build the whole thing in an evening.
Tests are good. Tests are important. This is well established nowadays (although many developers still get strangely zealous and defensive about tests). In an ideal world, TDD makes sense but for an MVP on a limited developer budget, it is unfortunately too costly. When there isn’t even a clear design for the product, its architecture, its domain model, data schema, APIs or class hierarchy, then, in my opinion, TDD is counterproductive. When building from scratch you need to be able to iterate quickly, and although TDD is good at driving development, it’s still Test Driven Development, not Test Driven Design.
I would recommend using tests to make sure any algorithmic stuff is implemented properly, but for a startup with limited time and resources, writing the remaining tests will have to take a back seat for now.
Again the CEO needs to be aware that this first product is essentially a prototype, and a product designed for long term support takes longer to build. When you come to do it properly then a comprehensive test suite with good coverage becomes invaluable, and TDD is a boon in that case.
6. Fake it til you make it
Sometimes you will find progress is blocked when parts of the product can’t be built until other parts of the business are in place.
In my situation part of the platform was a shopping cart application. We didn’t have any product catalogue data at the start, so rather than wait for the real data to arrive I simply invented some products. A simple script that outputs fake products helped here. Doing this let me refine the shape of the data that our platform needed, which was useful information that we could feed back to our suppliers.
On the front-end, rather than using Lorem Ipsum and wireframe placeholders, get hold of some free stock photography, and don’t be afraid to write the copy yourself. Ideally, these creative decisions would not be made by developers, but doing this creates another impediment before you can launch. If something is really bad it can be changed before launch, but otherwise, you can go ahead without having to inspect and replace all the content. During development, real content helps make the product look more complete, which is great when demoing it since it requires less imagination to see the final product — less time for investors to think “this looks good. I’m in.”
Conclusion
Many startups begin with little or no software development experience. As a consequence, from a software perspective, their first product is a badly engineered, unmaintainable shambles. I used to consider this a sorry state to be in, but that is no longer the case. I realise now that it’s OK, in fact, it’s good, not to spend too much effort building a well-engineered product as an MVP. The important thing is: plan to rebuild it properly.
