Shipping Quick @ Optimaze

How we ship a year's worth of work in a quarter

At OPTIMAZE, producing a year's worth of work in a quarter isn't an exception, it's what our process is designed to enable. Development here is AI-centric, augmented by humans, not humans with an assistant on the side. That doesn't mean letting AI generate code quicker than a person can review it, the unlock sits earlier, in how an idea becomes something concrete enough to build, and carries through to how the resulting code gets reviewed. Internally, ideas are improved through deliberate iteration rather than arriving fully formed.

Where it started

It was driven by a desire to capitalise on prevailing market opportunities, opportunities that required far greater productivity than a small team would ordinarily be able to deliver in the required timeframes. In any environment, every wait between product and engineering is lost productivity; in a startup this is untenable. So the founding goal was to empower engineers to think and act like product, and enable product to work as engineers, one process and one tool enhancing two streams.

What that meant in practice was splitting the path into the parts a human meaningfully contributes to and the parts an agent can carry on its own. Vision and design need the person: what is worth building, for whom, and why now. The how needs them much less. So the process is built to extract the intent and the outcome from the human, then hand the rest to something that can churn through delivery without stopping to ask.

The intention was to create a highly auditable, traceable pathway from discovery through to delivery, best practice embedded from the start so there's never a future question about how, why, or what was decided. Discovery starts with the problem and why the current state is insufficient, then maps the constraints the existing system carries and where the proposed solution improves on current approaches. Before going further, it checks the competitive landscape: whether anything in the market already fills the space. Customer outcomes and revenue or cost impact come next, and everything is reviewed against strategic intent and direction, decisions recorded as they're made. It's the same framing OPTIMAZE applies to any team's technology investment. When we build, we understand the capital performance of every feature, the cost to develop it and the cost to run it once live. What we ship is quantified by our own product, we measure OPTIMAZE in OPTIMAZE.

Once discovery is solid, the process doesn't jump straight to a recommendation; rather, options are presented with their pros and cons before anything is selected, each evaluated on its own merits. Rejected approaches stay in the record with a short rationale rather than disappearing quietly. A year later, the reasoning is still there to read, not sitting in someone's memory. It outlives the people who had it.

What we tightened

The approach served us well. However, as time went on we found discovery repeatedly drifted from the product problem into code-level detail. The fix was a single rule: the user is the visionary, the agent is the builder. Every question is tested against one standard: is this how or is this what and why?

The questioning got stricter too; answers get pushed until they're concrete, because a fuzzy answer early forces every downstream stage to guess at what it meant.

An impact analysis runs before anything gets written up, searching the existing system for what might be affected by the decisions made, surfacing consequences while scope can still change. The discovery outputs stay at what and why, never how, so discovery doesn't silently enable the creation of architecture that nobody agreed to.

The guardrails

Moving faster only counts if it's safe to move faster, and the same human-augmented approach carries through to review, not just discovery. Every pull request runs through automated security scanning and an AI reviewer that flags issues, requiring human review before approval goes through. It's risk based, and risk here is two things: how likely the change is to cause an incident in production, and what it would cost if it did. Scrutiny and sign-off scale with both. A low-risk fix moves through quickly, anything closer to sensitive data, billing logic, or core infrastructure gets a closer human look, and past a threshold human engagement is required rather than optional. The AI narrows what a reviewer needs to focus on, it doesn't replace their judgement on whether a change is safe to release.

The cost of each project runs through OPTIMAZE itself, the same platform we give finance teams trying to understand the capital return on their technology investment. Cost per feature, cost per sprint, cost per engineer: attributed and visible, rather than buried in a bill that arrives after the fact.

The numbers

The velocity target is one to two weeks from idea to production. Last quarter the team delivered a year's work, four engineers producing in three months what would ordinarily take them twelve, work that would traditionally have cost $1,000,000 in salaries to reach. The salaries were on the books already. What was added was $62,500 a year in AI tooling, a quarter of one engineer's salary, and that is the whole difference between a quarter and a year.

That's the same quantification discipline we build into the product, applied to how we build it.

The velocity target is one to two weeks from idea to production. Last quarter the team delivered a year's work, four engineers producing in three months what would ordinarily take them twelve, work that would traditionally have cost $1,000,000 in salaries to reach. The salaries were on the books already. What was added was $62,500 a year in AI tooling, a quarter of one engineer's salary, and that is the whole difference between a quarter and a year.

That's the same quantification discipline we build into the product, applied to how we build it.