A rewrite, a replatform, or turning an internal system into something you sell
The architecture the product grew into isn't the one it needs. That decision is made. What usually isn't made is everything underneath it - what the objects are, how they relate, and what has to exist before what.
A rewrite inherits every undecided thing from the version before it, unless someone stops and decides them on purpose.
What usually turns out not to be decided
- How the main objects relate. On one platform, users, contacts, vendor companies and three legacy permission levels were debated for weeks - while blocking the screen reviewers work in all day.
- Whether an action is one thing or several. "Reject" was drawn as a single button. It sends different notifications to four different parties.
- What must exist before what. A developer found he couldn't assign an object to a parent that didn't exist yet - a specification gap, not a coding problem.
- Whether a feature is actually its own product.
In a rewrite there's no existing behaviour to fall back on. Every ambiguity gets resolved by whoever hits it first, usually a developer, usually silently. Six weeks in, three people discover they were building three different things.
According to these figures, you’re losing about
$
a month
Book a fit call
What happens next:
- Fit call - We learn about your product and your situation. If it's not a fit, we'll tell you.
- Pilot - 2 weeks, $10,000 fixed. The question it answers: what have we not decided yet? We close the two or three most expensive gaps - named, dated, approved by your people. You see exactly how we work before committing to anything larger.
- Full engagement - scoped by product area. Every structural decision closed, the model they rest on - entities, relationships, states, lifecycle rules, dependency order - and a prototype of the target state.
