"Should we rewrite?"
Usually no. But "usually" isn't a plan, and a rewrite on a hunch burns six months.
I read the code your AI wrote, map the system you actually shipped, and tell you what to keep, what to fix, and what to leave alone, before you rewrite, hire, raise, or scale.
Drag the lens over the app. The dashboard is what you see. The X-ray is what you own.
Illustrative. Your curve is different. The shape usually isn't.
Each feature built on an unexamined assumption makes the next change more expensive. The agent doesn't slow down. The debt doesn't either.
You meet it during an outage, a security questionnaire, a diligence call, or your first engineer's first week, when "we should rewrite this" gets said out loud.
Not because today is special. Because every day after it, there's more to understand.
Today, your codebase is the smallest it will ever be. That's the best time to read it.
Each one is expensive to get wrong and cheap to get right, if you understand the system when it shows up.
Usually no. But "usually" isn't a plan, and a rewrite on a hunch burns six months.
The system you own decides the engineer you need. Hire for the wrong system and you hire the wrong person.
SSO, audit logs, tenant isolation, and a 200-question security review, due before the contract is signed.
Technical diligence asks questions about your system. You want to have heard them first.
A good launch is a load test you didn't schedule. Know where it bends before the traffic finds out.
Every change breaks two things and nobody knows why. That's an architecture problem wearing a productivity costume.
A fixed-scope audit of your AI-built product, aimed at the decision in front of you, with a clear answer at the end.
How your product actually works, drawn so a new hire or an investor can follow it.
What could hurt you, in order, and where in the code it lives. No generic checklists.
What's working, what matters now, and what you can safely ignore this quarter.
The next moves in order, sized so you (or your AI) can execute them.
We go through it together. Bring your questions and your co-founder.
NOT IN THE BOX Implementation, penetration testing, compliance certification, emergency response, and unlimited support. The audit gives you clarity. It doesn't make me your on-call.
Anyone can hand you a list of problems. The judgment is in what you deliberately leave alone. Here's the shape of a real memo.
B2B SaaS. Built in four months
with an AI app builder, Postgres, and
Stripe. 40 paying teams. Solo founder.
The decision: "Do we rewrite
before I hire my first engineer?"
It will carry you well past your next 10×. The tool isn't the problem.
One deployable is a feature at 40 customers. Microservices now would be a rewrite in disguise.
Customers like it. Ugly code that nobody complains about is not this quarter's risk.
One team can read another team's invoices through the API. Fix this week.
A retried webhook can provision a seat twice. Small fix, expensive bug.
Backups exist. Whether they work is a guess. Test one restore before you need it.
Buys nothing your customers or your next hire need this quarter.
You don't have that problem. You may never have it.
Cover the money path and the auth path. The rest can wait.
Don't rewrite. Fix three things in two weeks, then hire a product engineer, not a platform engineer.
A composite example, not a client. Real memos cite files, queries, and evidence.
I'm Abed Lawand, a working CTO and software architect. I build cloud systems for a living, and in my spare time I write 6502 assembly for a 40-year-old computer with 64KB of RAM. It still teaches me things no framework ever has.
Constraints reveal architecture. When nothing is hidden, you can finally see what you own.
That's the lens I bring to your product. No framework religion, no rewrite agenda. Just what's actually there, and what it means for the decision you're about to make.
The questions to ask about the software you built with AI, for founders and solo builders who shipped first and want to understand second. The audit applies those questions to your product.
Get updates in the newsletter →Practical notes on architecture, engineering judgment, and building systems that last. Written for people who ship.
No noise. Unsubscribe anytime.
You did the hard part: you shipped. Let's make the next decision a good one, while the system is still small enough to see whole.