Aizaz
An Upwork invite came in at $10 an hour for what initially sounded like a technical architecture role on a sales enablement product.
The product itself was easy enough to understand. It had contacts, accounts, deals, a dialer, campaigns, team management, coaching features, and connections to external data sources. There was already an early front end, and throughout the discussion it was still being described as an MVP.
Then I went through the architecture they actually expected behind it.
The system needed to support multiple companies, with multiple users inside each company. That meant tenant isolation, roles and permissions, and clear boundaries around who could access what. The architecture was expected to be metadata-driven, support custom objects, handle caching and bulk processing, expose APIs, and eventually provide hooks so other applications could extend the platform.
The longer-term vision went further. Other SaaS products could eventually be built on the same foundation, and there was discussion around something closer to an application marketplace where third parties could build on top of the platform.
None of those ideas were unreasonable on their own.
The interesting part was seeing all of them discussed while the product was still being called an MVP.
At that point, we were no longer just talking about the architecture behind a sales tool. We were talking about the beginnings of a platform.
And that distinction matters even more now that AI has made the visible parts of software much easier to build.
What the user sees and what the system has to support are two different things
A user might open the product and see a fairly normal CRM experience.
They can view a contact, move a deal, make a call, create a campaign, or manage their team.
None of those screens necessarily looks complicated.
But take something as ordinary as adding multiple organizations to the same product.
Now every part of the system needs to understand which organization a piece of data belongs to. Every query has to respect that boundary. Background jobs need to know which tenant they are working for. APIs need to enforce the same isolation as the interface. Permissions have to work consistently whether the user is clicking a button or another system is making a request.
Then add multiple roles inside each organization.
A salesperson might only need access to their own records. A manager might need visibility across a team. An administrator may need access to the entire organization. A custom object introduced later may need its own permission rules.
The role selector itself might be a very small feature.
The rules behind it can spread through almost every part of the product.
That is the part of software development that a prototype rarely shows.
AI makes ambitious scope feel cheaper
AI-assisted development has changed how quickly an idea can start looking like a product.
Interfaces that previously took much longer to put together can now be prototype quickly. Developers can use AI to generate repetitive code, create starting implementations for APIs, draft database models, work through bugs, and explore several technical approaches before committing to one.
That is genuinely useful.
The problem is that speed can change how we think about scope.
When adding another feature appears relatively inexpensive, it becomes easier to keep expanding the product. A sales application can gradually grow from managing contacts and deals into supporting dialing, campaigns, coaching, organization management, integrations, configurable data structures, external APIs, and eventually third-party extensions.
The product does not suddenly become complex because of one absurd requirement.
It becomes complex because many individually reasonable decisions begin interacting with each other.
A campaign system might depend on contacts, permissions, queues, communication providers, reporting, and billing. A customization object model might affect the database, search, APIs, permissions, and the user interface. A plugin system introduces questions around authentication, data access, compatibility, failure isolation, versioning, and documentation.
AI can reduce the effort required to implement parts of those systems.
It does not remove the relationships between them.
An MVP can have a scalable foundation without pretending it is already a platform
There is a temptation to treat this as a simple argument for building less.
I don't think that is the right lesson.
Some decisions absolutely should be made early.
If you already know that several organizations will use the application, tenant isolation is not something I would casually leave for later. If the product depends on several types of users having different access levels, permissions need to be treated as part of the architecture rather than bolted onto individual screens.
Those are foundational decisions.
The problem begins when everything the product might eventually become starts influencing what has to be built today.
Perhaps customers will eventually define completely custom objects. Maybe external developers will eventually need a plugin system. Perhaps several products will one day run on the same shared platform. An application marketplace could make sense when there is an ecosystem large enough to support one.
All of those things may eventually be correct.
But there is a difference between leaving room for that future and implementing that future before the current product needs it.
A scalable architecture does not mean every future capability needs to exist in version one.
Sometimes the best architectural decision is simply making sure today's implementation does not prevent tomorrow's change.
Generated code still creates permanent responsibilities
Plugin support is a useful example.
On paper, the requirement might be summarized as allowing third parties to extend the application.
In practice, that immediately raises questions. What can an extension access? How does it authenticate? Can it modify customer data? Does it inherit the same permission model as the main product? What happens when the core API changes? How are extensions versioned? Can one poorly behaving integration affect other tenants?
Once other developers depend on that interface, the product has created a contract it now has to maintain.
The same applies to custom objects, feature flags, event systems, APIs, and almost every other platform-level capability.
The first implementation is only part of the cost.
The system also needs to be tested as the rest of the product changes. It needs monitoring. Someone has to understand failures in production. Documentation has to stay accurate. Migrations need to work. New developers joining the project need to understand why the architecture works the way it does.
Whether the first version took three months to build or an AI coding tool helped produce it in a few days does not change that long-term responsibility very much.
This is why I've become less interested in asking whether a feature can be built.
For most reasonably scoped software requirements, the answer is eventually going to be yes.
The more useful question is whether the product is ready to own what that feature introduces.
The MVP-to-Platform Test
When a product starts accumulating platform-level requirements, I think there are five questions worth answering before those requirements automatically become part of the architecture:
- Is there current demand for it?
Is this solving a problem an existing user actually has, or are we designing for a customer we imagine we may have later? Future planning matters, but hypothetical users can justify almost unlimited infrastructure. - What is the real cost of postponing it?
Some decisions become extremely expensive to change later. Others only feel urgent because they are already being discussed. The important distinction is whether postponing the capability creates a genuine architectural trap. - How far does the requirement reach?
A feature that touches one screen is very different from one that changes authentication, billing, permissions, APIs, data ownership, and infrastructure. The amount of code is often less important than the number of systems the decision becomes connected to. - What do we own after it ships?
The work does not stop when the demo works. The capability has to be tested, deployed, monitored, documented, supported, and changed alongside the rest of the product. - Are we solving today's scale or imagined scale?
Building something that can grow is sensible. Engineering around volumes, organizational structures, or ecosystems that may not exist for years is a different decision.
I don't think this framework tells you to always delay ambitious architecture.
It forces the more useful conversation: which parts of the future are expensive enough to prepare for now, and which ones should earn their way into the product later?
The architecture remembers every yes
The biggest change AI brings to software development may not simply be that code gets written faster.
It changes the economics of saying yes.
When a feature obviously required weeks of development, there was natural pressure to ask whether it was really necessary. When a convincing first version can appear in a much shorter amount of time, that pressure gets weaker.
The prototype can make a decision look cheap.
The architecture is where its real cost starts showing up.
That does not mean we should stop building ambitious products. Some products should become platforms. Some companies need extensibility, multi-tenancy, configurable data models, and infrastructure that can support many products rather than one.
But those decisions should come from the needs of the product, not simply from how easy the first version has become to generate.
The $10 an hour invite was memorable because the gap between the description and the architecture was so visible. What sounded like an MVP for a sales product was already carrying expectations around multi-tenancy, metadata-driven systems, extensibility, and an eventual application ecosystem.
The larger vision may have been completely achievable.
The more important question was which parts of that vision needed to exist now.
That is the question I think becomes more important as software gets faster to produce:
Don't just ask whether you can build the platform. Decide when the product has actually earned the complexity of becoming one.