Launch Is the Halfway Point: What Happens After Your Software Goes Live

We built a license-management feature for an education provider that tracked how seats moved from one teacher to another. The provider expected teachers to cycle in and out of the product.

After launch, nobody used it. We eventually removed it.

A feature may work exactly as intended and still turn out to be unnecessary.

The point is that the work never goes down to zero.

Launch-and-leave depends on some big assumptions

The launch-and-leave model is common in software development because it lets the development team focus on one thing: building the tool. Once the tool is live, the engagement is over.

This assumes the software will work as intended and reach the audience as expected. It also assumes that circumstances will remain stable. You may even have launched without bugs, which never happens.

AI assistants and other development tools can make the build faster. They also make it easier to focus narrowly on development while overlooking the strategy, testing, education, measurement, and ongoing care around it.

What happens after your software goes live requires more than development speed.

The first month is an orientation period

Most teams launch more than a minimum viable product. When real users arrive, they are trying to understand the new product and how it fits into their work. The most common surprise is how much of the software they do not use.

Sometimes they do not know a feature exists or understand what it is for. That is an orientation and education problem.

Other times, they do not use a feature because they never needed it.

Real use shows you where people get confused, where they abandon a workflow, which features sit untouched, and which requests keep surfacing. Bugs are part of that first 90 days, but they are only part of it.

Three different jobs begin after software launch

1. Keep it running

At Fabrik Labs, this is part of our Product Stewardship work. At a minimum, it means fixing reported bugs. Depending on the engagement, it can also include monitoring logs and internal errors so we can address problems before they become visible to users.

The year-two section of our custom software cost guide explains the budget implications.

2. Get people to use it

Adoption usually belongs to the client. It requires orientation and education so people understand how the software fits into their work. We can help in a custom engagement, but adoption is outside our standard stewardship model.

3. Make it better

Improvement is shared work. We evaluate and organize requests within the guardrails of the stewardship agreement. A modest change to an existing feature may fit. A wholly new feature, or a large modification, usually waits for a new phase.

At some stewardship levels, the work focuses on keeping the product running. Higher levels can include proactive monitoring, modifications to existing features, and strategy work that captures larger requests in the product roadmap.

How 4MyCiTy went from manual check-ins to real-time reports is one place that third job shows up. The team went back after launch and changed the product from what they saw.

The Alliance learned by watching teachers use the product

Our work with the Alliance for Decision Education shows how that third job can change a product.

We built a tool that enhances a teacher’s existing lesson plan with content from the Alliance’s decision education database. The original lesson remained intact, with new sections inserted between the teacher’s material.

Once teachers used it, we saw that they had trouble distinguishing their original lesson from the added material. Subsequent versions improved the lesson output to retain the teacher’s document formatting, but inject clearly marked decision education content.

Teachers may be committed to decision education and still lack the time to do additional work on top of everything else. The continuing work is changing how we think about the tool’s role. The Alliance can use it to prepare assets ahead of time or work alongside teachers, leaving them to focus on teaching.

That direction came from seeing the product in use. The first version had not settled the question.

Ownership matters more than who provides it

I have seen products move in-house and slowly wither because the team responsible for them went away or turned its attention elsewhere. Nobody promoted the tool internally. Nobody kept up with changing user needs. The product became stale, users noticed, and its value declined.

Eventually, people drift back toward the spreadsheets and workarounds the software was supposed to replace. If that sounds familiar, compare what you are seeing with these 10 warning signs that you have outgrown your systems.

A clean handoff can still make sense. Your organization may have an internal or fractional person who can maintain the product, and you do not have to retain Fabrik, or any outside partner, forever.

That owner needs to understand the architecture and development stack behind the product. They also need product and design sensibility, plus the ability to work strategically with the rest of the organization.

The ability to generate code with AI tools does not replace that expertise. When the product or its platform changes, someone needs to understand the consequences and navigate them appropriately. An in-house owner can shepherd a product through all this and more.

Turn real use into the next plan

Once an owner is in place, they need a steady rhythm for watching the product. The pace can change, and the work does not have to happen every day.

Start with usage. Measure how many people use the tool and whether their frequency matches what you expected. Look for points where they abandon a workflow, and compare service requests before and after launch.

This is why we recommend building analytics and telemetry into software. It lets the team see how people use the product instead of treating it as a black box.

Route bugs and other feedback into a shared queue. Repeated requests should be visible without giving automatic priority to the loudest voice.

Before a new development phase, compare each request with the next goal. Does it help move the current product toward where the organization wants it to be?

This is where the distinction in What “Product” Really Means becomes practical. Launching the software does not complete the work around how people use it, support it, and decide what comes next.

Decide these three things before launch

The future will remain uncertain. Decide who will pay attention before the software goes live.

1. Who owns the product on your side?

Choose someone who participated in development and can see both the tactical and strategic sides of the work. This usually should not be the most senior executive. The owner becomes the day-to-day point of contact, prioritizes the queue, keeps track of what is happening, and knows when a decision needs to reach the executive sponsor.

2. What does success look like six months later?

Define the usage frequency you expect, whether that means daily or occasional use. Set expectations for how bugs and issues should decline after launch. Maintain a clear record of performance and missing capabilities.

Most importantly, identify the organizational measure the product is meant to change. For a self-service tool, success might include fewer requests reaching internal staff. The right measure depends on the problem you built the software to address.

3. How will feedback reach the team?

Create a clear channel before launch, and track urgent problems and nonurgent requests in the same system. Count repeated requests, but evaluate each one against the purpose and goals of the next phase.

Set a recurring review rhythm that fits the product and never drops to zero.

If you have already launched and the product is falling short, compare the current results with the outcome you stated before the build. If you did not state one, define it now. Then examine how the product was implemented and introduced, and whether you are reaching the right audience.

Already launched something that isn’t getting used the way you hoped? We’re happy to take a look.