This is a rewritten version of an article I originally published on DEV Community.
Someone once came to me with an idea for a startup.
They wanted to build a fashion and lifestyle super app.
The idea was to bring features that already existed across different apps into one place and build AI, AR and VR experiences around them. You could imagine trying on make-up virtually, seeing how apparel might look on you, all the while getting personalised recommendations and eventually having all of it connected through one platform, which also allowed you to purchase the product seamlessly.
They had thought a lot about the app.
They were excited about it, and honestly, it was interesting to listen to.
Some of those ideas would be difficult to build well, but that wasn't really the problem. Difficult problems can be interesting problems.
Once they had explained the whole thing, I started asking questions from a different direction.
What does the business look like?
Do you have vendors?
Do you have customers?
Are you already selling anything?
How much of this has actually been tested?
That was where things became less certain.
They had spoken to a few local vendors and shops and were looking for investors, but there wasn't really a business yet.
The app was supposed to come first.
The expectation was that the app would attract vendors, customers and eventually investors.
That is where I disagreed with the approach.
Not necessarily with the idea.
Rather I disagreed with the sequence of growth which the person wished to follow.
Build Enough to Find Out
My suggestion was simple.
Use what already exists.
For example, I suggested something like WorkOS for authentication and managed platforms such as Vercel or Cloudflare for hosting and infrastructure. For the AI parts, I suggested that we start with existing models and APIs wherever they can do the job.
These are problems other platforms have already spent a considerable amount of time solving. At this stage, I wouldn't spend money and engineering effort solving them again unless the business gave me a good reason to.
Build enough of the app to demonstrate what makes the idea interesting.
Then see whether anyone actually wants it.
Can you convince vendors to join?
Can you get customers to use it?
Will people buy through it?
If that starts working, you have something real to build on.
You also have something far more useful to show an investor instead of just a technical proposal.
That first version doesn't have to be the architecture you use forever.
It only has to get you far enough to learn what the business actually needs.
A little later, they came back with a document.
Around ten pages.
It contained the technologies, databases, infrastructure, model hosting and architecture they wanted for the platform.
It was designed for a much larger system than the one we were actually discussing.
So I started asking why.
One concern was vendor lock-in.
What happens if we depend too heavily on managed services?
What happens when the application grows?
Shouldn't we own these parts ourselves from the beginning?
These are valid engineering questions.
But timing matters.
If a managed service can comfortably handle the business you have today, replacing it because it might become a limitation someday is not solving today's problem.
You can replace authentication later.
You can move the workload elsewhere.
You can split things apart.
You can bring something in-house when it becomes important enough to justify doing so.
Systems change all the time.
I have worked on systems where exactly that happened.
The architecture that made sense at one stage stopped making sense later, so we changed it.
That isn't unusual.
What felt unusual was trying to solve those future problems before finding the first customers.
Designing for a Business That Doesn't Exist Yet
Eventually I realised where the detailed architecture had come from.
They had been discussing the idea with AI.
The app became more detailed through those conversations, and so did the architecture.
That explained some of the disconnect.
If you describe the complete version of this product and ask AI how to build it, you can get a convincing architecture for that product.
The problem is that the architecture answers the system you described.
It doesn't tell you whether you should build that entire system today.
Those are two different questions.
And when you don't have the technical context to judge the difference, a detailed answer can easily start feeling like a requirement.
Suddenly you are thinking about infrastructure for millions of users while still trying to find your first few users.
The App Still Needs a Business Behind It
This was ultimately the part I couldn't get past.
The application itself can be excellent.
The AI features can be impressive.
The AR experience might genuinely make the product stand out.
But this is still commerce.
What are you selling?
Who is supplying it?
Why would those vendors work with you?
Why would customers choose you over businesses they already know?
How are those products reaching customers?
What happens outside the screen matters just as much as what happens inside it.
An app can support a business.
However it cannot create all of those pieces automatically.
And that is why I would rather start with a smaller product attached to something real rather than a massive product built around assumptions.
Get a few vendors.
Get a few customers.
See what they actually care about.
Then the architecture has something to respond to.
Perhaps the AI experience turns out to be the reason people use the product. Great. Invest there.
Perhaps one of those managed services eventually becomes too expensive or too restrictive. Replace it.
Perhaps the system grows to the point where parts need to be separated and scaled independently. Do that when you know which parts these are.
You don't need to predict all of it in advance.
In fact, you probably can't.
The architecture you design after running a real business for a while will almost certainly be better informed than the architecture you designed while imagining one.
That conversation stayed with me because it wasn't really a disagreement about a particular technology.
It was about what should come first.
You can design an extraordinary platform for the business you hope to have.
Or you can build just enough to find out whether that business exists.
I'd start with the latter option.
