How Would I Build For Right Now
There’s a woman selling food on the street. Two years in. She restocks, pays her supplier, feeds her kids, shows up tomorrow. Not rich, not struggling. Moving.
Someone tells her she needs a proper system. Inventory tracking. Demand forecasting. A loyalty programme. Her friends are doing it. She learned about it in school. Serious businesses do this. So she sets it up. Spends time and money getting it right.
Six months later she’s still on the street. The system is on her phone, untouched. Her margins are thinner from the setup cost. The customers she was supposed to retain with the loyalty programme don’t own smartphones.
She didn’t fail because she was careless. She built for a version of her business that doesn’t exist yet and nearly killed the one that does.
Nobody warns you about this trap because it doesn’t look like one. It looks like ambition. It looks like doing things properly.
She never stopped to ask whether any of it served her right now. The standard said serious businesses do this, her mates were doing it, she followed it. The advice wasn’t wrong in the abstract. It was wrong for her, today, with what she had.
The question she never asked:
Does this serve the business that exists today, or a version that hasn’t arrived yet?
There’s a version of her business where inventory tracking makes complete sense. Twenty vendors, three locations, a proper supply chain. That version needs systems.
That version isn’t real yet.
The present needed to know what sold today, what to restock tomorrow, how much she made this week. A notebook solves that. She didn’t need a system. She needed to survive long enough to need one.
Software is the same problem in different clothes.
You get a project, a deadline, a client. Before you write a line you’re already making decisions about architecture, standards, what professional looks like. Most of those decisions happen on autopilot, based on what you were taught and what your peers are doing.
DRY. SOLID. Full test coverage. Sometimes that’s exactly right.
But sometimes you’ve got 30 days, one developer, and a client who needs 90% of this working end to end. And you’re five hours into an abstraction that would matter if three million people were hitting your server. You have three hundred users. Half of them are your own team.
Those five hours weren’t lost to bad code. They went to a problem that doesn’t exist yet.
This is not an argument against standards.
Some standards are load-bearing from day one. Building anything that touches money seriously, anything with compliance requirements, anything where a wrong number means someone’s rent doesn’t go through — tests, auditing, proper error handling aren’t optional there. You follow them because of what failure costs in that specific system, not because a textbook said so.
That’s the distinction. Some standards hold the thing up. Others are for a version of the system that doesn’t exist yet.
The first category doesn’t move regardless of deadline. The second goes on the backlog and you stay honest about it.
The vendor’s mistake wasn’t thinking about the future. Her mistake was building for it before the present was stable.
There’s an order of operations that matters here.
Can this thing function today? Can it make money, deliver value, hold up under the weight it carries right now?
After that, what does it need to survive the next version of itself?
Most people reverse this. They architect for version three before version one has a single real user. The product dies somewhere in the gap between the version they built for and the version that showed up.
Before I start anything now, two questions.
What does this need to work today? Not at scale. Not in six months. Today, with these users, this deadline, this team.
What does failure actually cost here? Is this a system where a wrong number destroys someone’s finances and their trust? Or is this one where a bug gets fixed in the next push and nobody lost sleep?
Those answers tell me which standards are non-negotiable today and which ones get deferred. Deferred, not ignored. Ignoring means you forgot. Deferring means you made a deliberate call and you know what it’ll cost later.
The code is just the answers made real.
The woman is still on the street. The system is still on her phone. Somewhere a developer is six hours into an abstraction for a codebase with three hundred users wondering why the deadline feels impossible.
Same problem. Wrong version.
I’m Damola, a backend engineer. Find the rest of this series on GitHub. Follow me on Dev.to for the next one.
Someone tells her she needs a proper system. Inventory tracking. Demand forecasting. A loyalty programme. Her friends are doing it. She learned about it in school. Serious businesses do this. So she sets it up. Spends time and money getting it right.
Six months later she’s still on the street. The system is on her phone, untouched. Her margins are thinner from the setup cost. The customers she was supposed to retain with the loyalty programme don’t own smartphones.
She didn’t fail because she was careless. She built for a version of her business that doesn’t exist yet and nearly killed the one that does.
Nobody warns you about this trap because it doesn’t look like one. It looks like ambition. It looks like doing things properly.
She never stopped to ask whether any of it served her right now. The standard said serious businesses do this, her mates were doing it, she followed it. The advice wasn’t wrong in the abstract. It was wrong for her, today, with what she had.
The question she never asked:
Does this serve the business that exists today, or a version that hasn’t arrived yet?
There’s a version of her business where inventory tracking makes complete sense. Twenty vendors, three locations, a proper supply chain. That version needs systems.
That version isn’t real yet.
The present needed to know what sold today, what to restock tomorrow, how much she made this week. A notebook solves that. She didn’t need a system. She needed to survive long enough to need one.
Software is the same problem in different clothes.
You get a project, a deadline, a client. Before you write a line you’re already making decisions about architecture, standards, what professional looks like. Most of those decisions happen on autopilot, based on what you were taught and what your peers are doing.
DRY. SOLID. Full test coverage. Sometimes that’s exactly right.
But sometimes you’ve got 30 days, one developer, and a client who needs 90% of this working end to end. And you’re five hours into an abstraction that would matter if three million people were hitting your server. You have three hundred users. Half of them are your own team.
Those five hours weren’t lost to bad code. They went to a problem that doesn’t exist yet.
This is not an argument against standards.
Some standards are load-bearing from day one. Building anything that touches money seriously, anything with compliance requirements, anything where a wrong number means someone’s rent doesn’t go through — tests, auditing, proper error handling aren’t optional there. You follow them because of what failure costs in that specific system, not because a textbook said so.
That’s the distinction. Some standards hold the thing up. Others are for a version of the system that doesn’t exist yet.
The first category doesn’t move regardless of deadline. The second goes on the backlog and you stay honest about it.
The vendor’s mistake wasn’t thinking about the future. Her mistake was building for it before the present was stable.
There’s an order of operations that matters here.
Can this thing function today? Can it make money, deliver value, hold up under the weight it carries right now?
After that, what does it need to survive the next version of itself?
Most people reverse this. They architect for version three before version one has a single real user. The product dies somewhere in the gap between the version they built for and the version that showed up.
Before I start anything now, two questions.
What does this need to work today? Not at scale. Not in six months. Today, with these users, this deadline, this team.
What does failure actually cost here? Is this a system where a wrong number destroys someone’s finances and their trust? Or is this one where a bug gets fixed in the next push and nobody lost sleep?
Those answers tell me which standards are non-negotiable today and which ones get deferred. Deferred, not ignored. Ignoring means you forgot. Deferring means you made a deliberate call and you know what it’ll cost later.
The code is just the answers made real.
The woman is still on the street. The system is still on her phone. Somewhere a developer is six hours into an abstraction for a codebase with three hundred users wondering why the deadline feels impossible.
Same problem. Wrong version.
I’m Damola, a backend engineer. Find the rest of this series on GitHub. Follow me on Dev.to for the next one.
Fuente: Artículo original