EvergreenWhen you are building something from scratch, speed feels noble.
It feels disciplined. Necessary. Mature, even.
You tell yourself you are being practical. The customer does not care if the code is beautiful. The market is moving. Cash is finite. Momentum matters. So you make the trade that almost every founder makes at some point: ship now, clean up later.
I understand that instinct very well because I have lived inside it.
As a founder, you are not operating in the comfort of theory. You are making decisions with incomplete information, limited time, and a product that still needs to prove it deserves to exist. In that stage, a lot of engineering advice sounds suspiciously like it was written by people who have never had to get a real product out before the window closes.
So yes, you move fast.
You hardcode things that feel temporary. You defer cleanup. You choose the version that works over the version that would make your future self proud. You call it pragmatism, which it often is.
The trouble is that pragmatism has a habit of overstaying.
And that is the trap.
Because some shortcuts buy you speed. Others quietly sell off your future ability to move.
It took me time to really understand that distinction.
Founding teaches you that speed has layers
Before I started building products as a founder, speed felt simple. Ship the feature. Get the customer. Keep going.
Later, I learned that there are at least two kinds of speed.
The first kind gets you to launch.
The second kind lets you keep moving after the launch.
The first kind is exciting. It is visible. It gives you demos, momentum, first users, first revenue, first proof that you are not completely hallucinating the opportunity.
The second kind is quieter. It shows up months later when the product has more customers, more complexity, and more reasons to break. It is the speed of a system that can still change safely. A team that can still ship without fear. An architecture that has not turned every roadmap discussion into a negotiation with old shortcuts.
That second kind of speed matters more than most founders realize at the beginning.
Not because launch speed is unimportant. It is. But because a lot of early decisions are effectively loans against future product velocity. Some are cheap. Some come with absurd interest.
I have learned to care a lot about the difference.
Tinker made that lesson very real for me
A lot of my thinking about this became sharper through building Tinker.
On my site, I describe the work I do as building systems that work well, scale reliably, and last. I also say, pretty plainly, that I prefer simple, well-designed systems over clever ones. (edgar.co.ke) That sounds neat and composed on a website. In real life, those principles are usually learned while the system is trying to embarrass you.
With Tinker Payments, the public story is clear enough: it is built as a unified payment infrastructure layer that helps merchants keep their existing payment providers while improving routing, reconciliation, revenue visibility, and payment stability. The product talks directly about hard operational realities: failed transactions, multiple providers with no unified control, manual reconciliation, operational risk during expansion, and the need for failover, routing, and finance-ready visibility. (Tinker Payments)
That kind of product does not come from a world where software gets to be casual.
Payments are rude in a very educational way. They force honesty. They are full of edge cases, provider inconsistencies, operational risk, money movement, reconciliation headaches, and all the little realities that punish vague engineering. If a content site is messy, people get mildly annoyed. If a payments system is messy, the consequences become much more memorable.
That is one of the fastest ways to learn that not all technical debt behaves the same.
Some debt sits quietly in a corner.
Some debt inserts itself into every future release.
The founder’s trap is not mess. It is sticky mess.
I think founders sometimes get bad advice here from both sides.
One side says, “Move fast and break things,” which is exciting until the thing you break becomes your main business.
The other side says, “Design it properly from the beginning,” which sounds responsible but can drift into building a cathedral for customers who have not even arrived yet.
Neither extreme is very helpful.
Early-stage products are allowed to be imperfect. In fact, they usually have to be. You do not need premium architecture for a problem that has not earned it yet. You do not need six layers of abstraction to prove a customer pain point. You do not need to act like a Fortune 500 platform on day one just because you have seen enough conference talks to know the vocabulary.
But you also cannot treat every shortcut as harmless.
What matters is whether the mess stays local.
That is the phrase I keep coming back to: local mess.
If a decision creates a bit of ugliness in a low-risk part of the system, I can live with that. Maybe an internal tool is rough. Maybe a report is manual. Maybe some workflow is embarrassingly human behind the scenes. Fine. Startups do not die because an internal admin page has poor taste.
The dangerous stuff is the sticky mess.
The kind that lands in your core data model. Your money flows. Your permissions. Your deployment path. Your integration boundaries. The places where every future product decision has to pass through.
That debt does not stay local.
It spreads.
And when it spreads, it stops being a shortcut and starts becoming culture.
You learn very quickly where “later” likes to hide
One of the funniest lies in software is “we’ll clean it up later.”
Not because nobody means it. People usually do mean it. The problem is that “later” is a magical place where teams imagine they will have more time, more certainty, more energy, and fewer urgent feature requests than they currently do.
This place does not exist.
Later is usually just now, but with more customers and worse consequences.
I have seen this happen enough times that I no longer hear “temporary” the way I used to. Temporary code has an incredible survival instinct. It clings to relevance. It learns the product. It gains dependencies. Before long, a rushed workaround is sitting in the middle of a critical flow like it pays rent.
And then your roadmap starts reacting to old decisions.
A simple change takes longer because an early assumption is now everywhere.
An integration becomes painful because the original model was too narrow.
A release feels risky because operational control was never built in properly.
Finance needs clean reporting, and everyone suddenly discovers that “we’ll sort that out later” has become a monthly ritual involving spreadsheets, detective work, and unusually long sighs.
You do not feel technical debt all at once. You feel it as drag.
That is what makes it dangerous. It rarely arrives like a dramatic collapse. It arrives like friction in everything.
Building in payments sharpens your sense of where to be strict
One thing I appreciate about building in this space is that it punishes hand-wavy thinking.
Tinker’s public product language talks about routing, failover controls, revenue visibility, a unified ledger view, reconciliation, and governance controls. (Tinker Payments) Those are not decorative features. They are responses to the kinds of operational problems that appear when real businesses are moving money through multiple providers and need control without replacing their entire stack. (Tinker Payments)
And that is exactly where founders need judgment.
Because when you are building something like that, the temptation is strong to keep saying yes to the fastest route. But some parts of the system do not forgive casual decisions.
Anything close to the movement of money deserves respect early.
Anything that affects reconciliation deserves respect early.
Anything that determines system behavior under provider failure deserves respect early.
Anything that will be used to explain reality back to finance, operations, or customers deserves respect early.
You can be scrappy in a lot of areas. You cannot be vague in the parts of the product that define truth.
That lesson reaches beyond payments, by the way. Every company has some equivalent of this. Some layer where the business becomes real. That layer deserves more care than the rest, even in the early days.
Founders do not need less speed. They need better spending
This is the part I feel most strongly about now.
I do not think founders need to be told to slow down. Usually they need help spending speed more wisely.
Because speed is not free. It is budgeted.
Every rushed decision spends some of it now and may borrow some from later.
The real question is not whether to take shortcuts. You probably will. You probably should, sometimes.
The better question is: where can we afford to be messy without making the future expensive?
That is a very different conversation.
It moves the discussion away from vague arguments about craftsmanship and into something much more useful: risk placement.
If this shortcut fails, where will the pain land?
Will it land in an internal tool nobody depends on heavily? Fine.
Will it land in the company’s core workflow, where every new feature has to pass through it? Different story.
Will it create a small cleanup project later? Acceptable.
Will it quietly tax every release, every estimate, every onboarding experience, and every incident? That is not a shortcut. That is a subscription.
That is the kind of thing technical leadership is supposed to help with.
Not to be the department of “no.” Not to turn startup life into an architectural prayer circle. But to help founders distinguish between debt that buys speed and debt that steals it.
The human side of this is easy to miss
There is also a more personal side to all this that people do not always talk about.
Bad debt does not only hurt systems. It wears down teams.
You can feel it when engineers start sounding cautious in the wrong way. Not thoughtful. Guarded.
You can feel it when estimates become padded because nobody trusts how deep a “small change” might go.
You can feel it when product conversations get slower because everyone knows the system has hidden moods.
You can feel it when the business starts asking for momentum and the team, quietly and correctly, starts asking for oxygen.
That is one reason I care so much about clarity now.
Not because clarity is aesthetically pleasing, though it is.
Because clear systems are kinder to the people building them.
They lower the emotional tax of change.
They make growth feel less like carrying furniture up a staircase designed by an enemy.
And when you are building for years, not weeks, that matters a lot.
Success changes the meaning of early decisions
One of the strange things about startup success is that it makes your old shortcuts more consequential.
When nobody is using the product, a rough edge is just a rough edge.
When the product starts working, every old compromise gets promoted.
The “good enough for now” data structure suddenly supports important reporting.
The rough operational process suddenly matters to multiple teams.
The workaround that got you past one provider issue now shapes how people think about the whole system.
That is why eventual success can make early technical choices feel heavier, not lighter.
And it is also why I think founders should talk more openly about this stuff. Not in a dramatic “we suffered for our architecture” way. More in an honest way. Building companies means making tradeoffs under pressure. Some of those tradeoffs are smart. Some are survivable. Some are educational in the expensive sense.
The goal is not to pretend you can avoid all of them.
The goal is to get better at choosing which ones deserve to follow you into success.
What I believe now
I still believe in moving fast.
I just no longer confuse movement with velocity.
I have become much more interested in systems that stay clear under pressure, products that can evolve without heroic effort, and technical choices that leave room for growth instead of charging rent on it.
That is part of why my writing and work keep circling the same themes: clarity, durability, systems that last. (edgar.co.ke) Those ideas did not come from abstract admiration for neat architecture. They came from building in environments where complexity becomes real very quickly, and where the cost of bad decisions is measured not only in code, but in operational strain, business risk, and team energy.
Founders will always need speed.
The real challenge is keeping that speed from turning against you.
Because the trap is not shipping fast.
The trap is shipping in a way that makes future speed harder to afford.
And once you have felt that trade in a real system, you start treating simplicity with a lot more respect.