How Would I Build For Right Now

#webdev #programming #career #beginners

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. She looks around and the people doing well all have these things. The businesses she admires run on proper systems. 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 looked at people succeeding and copied what they were doing. Those businesses had enough money to be wrong. They could try a loyalty programme, watch it fail, absorb the cost, and move on. She couldn't. Same pattern, completely different consequence. Nobody told her that part.

She also built for a version of her business she had no evidence for.

She knew what sold each day. She knew when she ran out. She knew what she made each week. That was her data. That was her use case. Everything else the forecasting, the loyalty programme, the full system was a guess she dressed up as a plan.

Your use case is defined by evidence, not aspiration. What you have data for is the only thing you are qualified to build for right now. Everything else is a guess wearing the clothes of planning.

The data is what makes the problem real. No data, no problem, no justification to build for it.

There is a version of her business where inventory tracking makes complete sense. Twenty vendors, three locations, a proper supply chain. The businesses she was copying were probably at that version or past it.

She had no data saying her business was heading there. No evidence the loyalty programme would land. No proof the forecasting would matter. Just the image of people further along than her, doing things that worked for where they were, not where she was.

The present needed to know what sold today, what to restock tomorrow, how much she made this week. A notebook solves that. She did not need a system. She needed to survive long enough to need one.

Software is the same problem.

You get a project, a deadline, a client. Before you write a line you are already making decisions about architecture, standards, what professional looks like. Most of those decisions happen on autopilot, based on what you were taught, what your peers are doing, what the successful companies are running on.

Everyone knows Netflix uses microservices. Everyone knows the big fintech companies have event-driven architectures. So a new startup gets pitched the same thing on day one, by someone who means well, pointing at companies with thousands of engineers and years of data justifying every layer of that complexity.

You have a 30-day deadline, one developer, three hundred users. Half of them are your own team testing the thing.

Those companies had enough engineering capacity to absorb getting it wrong. You do not. Same pattern, completely different consequence. And you have no data for that complexity.

This is not an argument against microservices or any pattern.

Nothing is premature if you have evidence for it. The moment you have real traffic, real bottlenecks, a team size that makes a monolith genuinely painful, the architecture that fits that data is not premature. It is the answer the evidence is pointing to.

The problem is never the pattern. It is the absence of data that justifies it.

Some things are load-bearing from day one regardless of scale. Building anything with compliance requirements, anything where a wrong number means someone's rent does not go through tests, auditing, proper error handling are not optional there. You follow those standards because the data about what failure costs is already clear. A wrong transaction is not a bug you patch quietly. It is a disaster with a paper trail.

That is the distinction. Some standards are justified by the data in front of you today. Others are borrowed from a version of the system you have no evidence for yet. The first category does not move. The second goes on the backlog.

There is an order of operations that matters.

Can this thing function today? Can it make money, deliver value, hold up under the weight it carries right now? Do you have data that tells you what today looks like?

After the present is stable, what does the evidence say about where this is going?

Most people reverse this. They architect for version three before version one has a single real user. The vendor bought a system for a business she had not built yet. The developer ships microservices to three hundred users because a company with three million users made it look like the right move.

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 the data say this needs to work today? Not at scale. Not in six months. Today, with the users that exist, the deadline that is real, the team that is here.

What does failure cost in this specific system? Is this the kind of 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 with full awareness of what it will cost later.

The code is just the answers made real.

The woman is still on the street. The system is still on her phone. The people she copied are still running their bigger businesses, probably unaware she was ever watching.

Somewhere a developer is six hours into a distributed architecture for a product with three hundred users, building for a version of the problem they have no data for, wondering why the deadline feels impossible.

Same pattern. Borrowed from people who could afford to be wrong with it. Applied somewhere it was never meant to land.

I'm Damola, a backend engineer. Find the rest of this series on GitHub. Follow me on Dev.to for the next one.