Architecture & Technical Strategy
A decision is coming that's hard to undo. It's much cheaper to think it through now than to find out in eight months.
- Who this is for
- Founders, CTOs, and engineering leads facing a decision they'll be living with for years. Often people who already have an instinct about the answer and want someone with no stake in it to check.
This sounds familiar if…
- The system is struggling in ways that aren't obviously fixable.
- Technical debt has started costing real delivery time.
- A big architectural decision is coming up.
- Someone has proposed a rewrite.
- You're building a new product on top of the existing one.
- Growth is coming and you're not sure what breaks first.
- You want a second opinion from someone with nothing riding on the answer.
One or two of these is normal. Four or five usually means the cause sits underneath all of them.
How I help
I look at what you have, what you're planning, and what's likely to break between here and there. Then I tell you what I'd do, including the parts I'd leave alone, which is usually more of it than people expect.
I've split monoliths without downtime, built systems handling tens of millions of events a second, and rebuilt a codebase by hand that should never have been generated in the first place. Most of what I've learned is about what not to touch.
Most systems don't need to be replaced. They need two or three things fixed and one thing decided properly.
Architecture Review
Start with an Architecture Review
I read the system and the plan, talk to the people who maintain it, and come back with an honest view of what's actually at risk.
What I look at
- The architecture as it exists, not as documented
- Major components and how they depend on each other
- Data flows and where they get complicated
- Infrastructure and what it costs to run
- Scaling and reliability risk, specifically
- Technical debt worth paying down, and debt worth keeping
- The constraints your team actually works under
- What you're planning to build next
What you get back
- Where you are now, described plainly.
- The real risks, separated from the theoretical ones.
- What should stay. What should change.
- A target architecture worth aiming at, and a migration plan that doesn't require stopping everything else.
- The decisions I think you should deliberately postpone, and what you'd need to know to make them later.
- How long
- A few days to two weeks
- Language
- English or Hebrew
- Where
- Tel Aviv, or remote
Depends on how much system there is. Send me a rough shape of it and I'll tell you what it takes.
Where this usually goes.
Take the letter instead.
I've written about this.
Not marketing pieces. Just the parts I was still thinking about after work.
Two other things I get called about.
Tell me what's going on.
A few sentences is plenty. What's happening, roughly how big the team or organization is, and the thing you'd fix first if you had the time.