Pivoting the Product: What to Reuse and What to Throw Away

When you pivot, reuse the layers that are about how software is built, not what it does: authentication, payments, infrastructure, CI and tests, and admin tooling. Throw away or rework the layers that encode the old product: the domain data model, the specific business logic and the screens. Sort each layer deliberately, so a pivot does not quietly become a full rebuild.

If you would rather have that sorting done on evidence and the reusable parts carried across for you, see how RAITHub would help below. This guide is for a founder changing what the product does and unsure how much of the existing code survives. It covers what a pivot really changes, which layers reuse well, a decision matrix, and how to carry the keepers across without starting from zero.

What does a pivot actually change?

Usually the problem you solve and the customer you solve it for, not the entire machine underneath. A pivot can be small (same customer, different feature) or large (new customer, new problem), and how much code survives scales with that. The common error is treating any pivot as permission to delete everything and start clean, because starting clean feels decisive. It is also the most expensive option, and it discards the parts of the old build that had nothing to do with the old product.

The useful way to think about a codebase during a pivot is in layers. Some layers are about how software is built and are product-agnostic. Others encode what the old product did. The first kind travels with you; the second kind is what the pivot is changing.

Which parts of a codebase usually survive a pivot?

The plumbing, because it does not care what the product is. These layers are often the slowest to build the first time and the most reusable:

• Authentication and user accounts. Sign-up, login, password reset and roles work the same whatever the product does.
• Payments and billing. Taking money, subscriptions and invoices are product-agnostic and painful to rebuild.
• Infrastructure and deployment. Hosting, the database setup, environment configuration and CI are a running foundation.
• The test and release machinery. Your CI gates and the discipline around releases carry across untouched.
• Admin and internal tooling. The screens your team uses to run the business are often reusable with small changes.

Keeping these is why a pivot is almost always cheaper than a first build. You are not starting from zero; you are starting from a working foundation.

What usually has to go, or be reworked?

The layers that describe the old product. These are exactly what the pivot changes, so expecting to keep them is what turns a pivot into a frustrating half-rebuild.

• The domain data model. The tables that describe the old product's core objects. If the new product is about different things, forcing it into the old schema is the single most common reason pivots stall.
• Product-specific business logic. The rules that only made sense for the old product.
• The user-facing screens. The flows and pages built around the old journey usually need to be rebuilt for the new one.

The data model deserves the most care, because data is the hardest and riskiest thing to migrate. Decide early whether any existing data is worth carrying to the new product, and keep the old data accessible until you are sure.

A decision matrix: reuse, rework or discard

Sort each layer against two questions: does it depend on what the old product did, and does it still work? That gives a clear verdict for most of the codebase.

Layer	Depends on the old product?	Usual verdict
Authentication, accounts, roles	No	Reuse as is
Payments and billing	No	Reuse, adjust only the plans and pricing
Infrastructure, deploy, CI	No	Reuse the foundation
Tests and release gates	Partly	Reuse the machinery; rewrite tests tied to old features
Admin and internal tooling	Partly	Rework; usually cheaper than rebuilding
Domain data model	Yes	Rework or replace, migrating only data worth keeping
Product business logic	Yes	Discard the parts the pivot removes
User-facing screens for the old journey	Yes	Rebuild for the new journey

If the new product barely resembles the old one and little of the foundation is sound, a cleaner start may genuinely cost less; the trade-offs are in rewrite vs refactor legacy code. For most pivots, though, the foundation is the reason not to start from scratch.

How do you carry the reusable parts across?

Build the new product on the existing foundation, feature by feature, rather than copying the old repository and deleting as you go. Deleting leaves behind references, dead tables and half-removed logic that are slow to track down. The cleaner path:

1. Keep the plumbing repository as the base. Auth, payments, infra, CI and tests stay where they are.
2. Add the new data model alongside the old, and migrate only the data worth keeping, verified before you rely on it.
3. Build new screens and logic against the foundation, leaning on the tests and release gates you already have.
4. Retire the old product's tables, logic and screens last, once nothing references them, so you are never in a broken middle state.

Do-it-yourself estimate: sorting the layers with the matrix above is a day or two for a senior engineer; carrying the foundation across and standing up the new data model is typically 2 to 4 weeks for a small product, far less than a first build. The main risk of doing it alone is sunk-cost reasoning in both directions: keeping old logic that the pivot should remove, or discarding a working foundation because starting clean feels better.

Buy, build or hire?

Option	Choose this when	Watch out for
Rent more off-the-shelf services	The pivot needs capabilities you do not have, like new payment rails	Renting auth or payments you already built is paying twice
Your own team carries it across	They know the codebase and can sort the layers honestly	Sunk-cost reasoning; keeping old logic the pivot should cut
An outside team sorts and migrates	You want an impartial read on what survives, or the original builders are gone	Make sure the data migration is verified, not assumed

When don't you need outside help?

• Your team knows the code and can sort the layers without bias. The matrix above is enough to start.
• The pivot is small. Same customer, one new feature; you are extending, not pivoting the foundation.
• You want engineers placed in your team by the hour. RAITHub works fixed-scope or as a dedicated monthly team and does not offer staff augmentation.
• You need a native mobile app or delivery in a language other than English. RAITHub builds web products in English only.

How RAITHub would help

Scope, agreed in writing before work starts:

• A layer-by-layer assessment of the existing codebase: what to reuse, rework or discard, with the cost of each.
• The reusable foundation carried across: authentication, payments, infrastructure, CI and tests.
• The new data model stood up alongside the old, with only the data worth keeping migrated and verified.
• New screens and logic built on the foundation, with tests on the money paths gated in CI.

Timeline: a short assessment, then a fixed-scope build of the pivoted product in 4 to 6 weeks on a sound foundation, in line with the SaaS and MVP ranges; larger pivots are fixed in writing after the assessment.

You receive: automated tests and CI, handover docs and runbooks, and full IP under NDA.

If the pivot is really the signal that the first version has outgrown its foundations, read your MVP outgrew itself, and how not to build an MVP covers the scoping mistakes a pivot is a chance to avoid repeating. The SaaS development service lists what is included; book the free 15-minute technical audit and bring what the product is pivoting to.

Frequently asked questions

Should I throw away my code when I pivot?

No, not all of it. Reuse the product-agnostic layers: authentication, payments, infrastructure, CI and tests, and usually your admin tooling. Throw away or rework the layers that encode the old product: the domain data model, product-specific logic and the old screens. A pivot changes what the product does, not how it was built.

What parts of a startup codebase are reusable after a pivot?

The plumbing, because it does not depend on what the product does. Authentication, payments and billing, hosting and deployment, CI and release gates, and internal tooling are often the slowest things to build first and the most reusable, which is why a pivot usually costs less than a first build.

Why does the data model matter most in a pivot?

Because data is the hardest and riskiest thing to migrate, and the model encodes what the old product was about. Forcing a new product into the old schema is a common reason pivots stall. Decide early what data is worth carrying, and keep the old data accessible until you are sure.

Is a pivot the same as a rewrite?

No. A rewrite replaces the whole product with new code. A well-run pivot keeps the working foundation and rebuilds only the layers the pivot changes. Treating a pivot as a full rewrite is the most expensive way to do it and discards work that had nothing to do with the old product.

How long does it take to pivot a product?

Far less than a first build if the foundation is sound. Carrying the plumbing across and standing up a new data model is often 2 to 4 weeks for a small product, versus the weeks to months a first build takes. Only a short assessment can price your specific case.

How do I avoid the pivot becoming an accidental rebuild?

Sort the codebase layer by layer before touching it, keep the reusable foundation as your base rather than copying and deleting, and build the new product on top feature by feature. Retire the old tables, logic and screens last, once nothing references them.