Beta Acid

Every project we work on boils down to either building software from scratch or rebuilding an aging system. There’s a lot of best practices we follow for both.

• Write clean code
• Make the user interface intuitive and beautiful
• Communicate clearly amongst our team and the client
• Focus ruthlessly on what delivers business value

These are the table stakes for every engagement we work on. But new builds and re-builds have their own unique challenges that we approach in distinctly different ways.

New Builds

When a client brings us an idea for a new software product we borrow from Eric Ries’ Lean Startup playbook. Lean startup emphasizes the rapid launch of a Minimum Viable Product (MVP) that tests a core market assumption. We then measure what users actually do, not what they say. That feedback drives each next iteration.

How That Looks in Practice

Leadership Alignment — Before a single wireframe is sketched, we sit down with the executive sponsor and product lead to nail two things: the business goals and the constraints (timeline, budget, compliance). This keeps every later conversation grounded in “will it help achieve our north star goals?” rather than “wouldn’t it be cool?”

Frequent Scope Sessions — After the north star goals are locked, we shift into working sessions with the client. These are hands-on, detail-level conversations about requirements, edge cases, and trade-offs. Together we clarify what’s truly in scope for the launch, what can wait, and how each choice maps back to the goals set with leadership.

Re-Builds

Rebuilds fool people with apparent simplicity, we often hear some variation of

Just re-create our existing platform on a modern stack.

Hidden beneath the surface are any number of edge cases that only arise once you really dig into the details.

Why Rebuilds Go Off the Rails

The longer a system has been around, the more oddball scenarios have accumulated in the code. Phrases like “Remember that for users in Luxembourg we added that custom tax rule…” are not uncommon. If you don’t uncover those quirks up front, they derail the schedule later. Another thing that happens on every rebuild: long-standing feature requests bubble up. Stakeholders inevitably say, “while you’re in there can you just add…”. This is completely fine, it just needs to be planned for from the start to avoid any big surprises to the timeline.

Keeping Rebuilds on Track

Unlike in a new build where we’re creating an MVP to quickly validate market assumptions, in a re-build we focus on mapping out existing features, data flows, and integrations. Then we dive deep to uncover the edge cases and quirks that have built up over the years.

For each item, we work closely with the client to decide: should we migrate it as-is, redesign it from the ground up, or drop it entirely?

• Modern UX Pass. Even if the charter is “same features, new tech,” we still recommend running user-flow mapping. A straight port rarely delights anyone; small UX tweaks often unlock huge efficiency gains.
• Prioritized Roadmap. Not every historical edge case deserves a place in the first release. The executive sponsor signs off on what ships now versus later, keeping scope small enough to deliver in months, not years.
• A Safety First Rollout. We recommend migrating services piece by piece to minimize risk.

Wrap up

Whether we’re launching something brand new or breathing life into something old, our job is to move fast, stay focused, and deliver software that actually gets used. Different playbooks, same obsession: ship real value, fast. Have an idea for a new product, or have a legacy tool that needs to get rebuilt fast, let's get in touch and talk through how we can apply these principles to your project.