A startup is a race to test hypotheses. Money is limited, time is limited, the market is unknown, and every week not spent on the main question, "do people need this", brings the company closer to the end of the runway. In this setting the word "architect" sounds almost like a curse. Why do we need someone who will draw diagrams and talk about scaling when we do not have a single paying client?
I understand that scepticism and partly share it. I have seen startups die of architecture: they spent six months building a perfect microservice system, and when they reached the market it turned out nobody needed the product in that form. But I have also seen the opposite: startups that found their market, started growing, and then got stuck for a year because a system slapped together in a hurry could not be developed further. So does a startup need an architect? Yes. But his role there is completely different.
Not a starship, but a runway
There is a temptation many technical founders give in to: building a starship. A system designed for millions of users, with perfect architecture, on trendy technologies. It is pleasant, intellectually exciting, and almost always deadly for a startup. A starship takes long to build and costs a lot, and there is nowhere to fly yet.
An architect's job in a startup is not to build a starship but to provide a runway. To make sure the small, light plane (the MVP) takes off as fast as possible, and if the flight goes well, it can be improved without being taken apart down to the last screw. It is an entirely different mindset: not "how to make it perfect" but "how to make it good enough without closing the road to the future".
Adaptability: being ready to turn
Almost every successful startup has sharply changed direction at least once. A product designed for some clients turned out to be needed by others. A feature considered secondary became the main one. The English word for this is pivot.
A good startup architecture is built so that a business pivot does not require rewriting ninety percent of the code. That does not mean foreseeing every option, which is impossible. It means keeping the system simple, modular and with a clearly separated core. If the logic for clients, payments and data is separated from a particular interface and a particular scenario, then during a pivot the superstructure changes and the foundation stays.
I compare it to a tent and a house. A tent can be pitched quickly and moved quickly if the campsite turns out to be a bad one. A house is more reliable but cannot be moved. At an early stage a startup needs a good tent: light, but not leaking in the first rain. The architect's job is to tell a tent from a shack that will collapse in the wind.
Technological hygiene
An architect's second important task at the start is almost invisible, but its price shows a year later. It is the choice of tools. Programming language, framework, database, hosting.
The rule is simple: choose boring, widespread technologies. Those used by thousands of programmers, with a big community, good documentation and well-known solutions to typical problems. An exotic language may be more elegant, but when six months later you urgently need to hire three developers, you will find them in a week for a popular technology and in three months for an exotic one. And three months for a startup is an eternity.
This also covers things that seem minor: version control, automated deployment, database backups, at least minimal tests for critical scenarios like payment. It is like washing your hands: it takes a minute and saves you from diseases that are very expensive to treat later.
The architect as a translator
There is one more role of an architect in a startup that is rarely mentioned. He is a translator between business and technology. A founder comes with an idea, and the architect helps him see which part of the idea is technically cheap and which is expensive. It often turns out that eighty percent of the value can be had for twenty percent of the effort if the wording changes a little.
A client once asked us to build a complex machine-learning recommendation system into his MVP. We asked which hypothesis he wanted to test. It turned out the question was whether people would use recommendations at all. A manual "popular this week" list, updated by a manager once a day, was enough for that. The hypothesis was tested in a couple of weeks instead of several months. People liked the recommendations, by the way, and machine learning arrived in the second version, on real data.
When an architect is not needed
If you are testing demand with a landing page, manual sales or a prototype built on a no-code tool, you do not need a separate architect. You will need one when you start writing code you plan to develop further rather than throw away. At that stage even a few hours of consultation with an experienced architect can save months.
In a small startup the architect's role is often played by the technical co-founder or CTO. That is fine, as long as he has experience and can restrain himself from building starships.
What we do
At Ingello Systems we often work with startups at exactly this stage. Our approach: quickly describe the domain model, generate a working prototype with a proper data structure in Fractal, and test hypotheses on it. The result is that very runway: the prototype appears in days, not months, but it sits on the right foundation to build on if the flight succeeds.
If you are a startup founder, ask yourself: what happens to your system if tomorrow you decide to change your target client? If the answer is "we'll have to rewrite everything", you need an architect. Not for the starship, for the runway.
