Most proposals spend pages on the build and a paragraph on everything after it.
That is backwards. A website or a custom system might take a few months to build and then run for five or ten years. The build is the short part. What happens after launch decides whether the thing you paid for keeps working, keeps improving, or slowly becomes something nobody wants to touch.
Buyers know this, even when proposals do not address it. On sales calls, the after-launch questions come up constantly. The co-founder of one sports-data company asked:
Do you guys also do ongoing 24/7 maintenance in case something goes down on the site?
An operations lead at a small-business services company asked a version every buyer should ask eventually:
What is our service agreement now regarding fixes? What does that look like for us?
Here are the questions worth asking before you sign, and what a good answer sounds like.
"Who Answers When Something Breaks?"
Ask for a name, not a process.
The answer you are looking for is a specific person, or a small team, who knows your system and can act without a long handoff. A general support inbox or a ticket portal staffed by people who have never seen your code means every incident starts with someone learning your system from scratch.
Then ask the follow-up: what if that person is unavailable? One partner at a publisher we work with put it directly:
Is there another person at your company that we could have as a backup just in case, like you weren't available or something like that?
A good answer names the backup, and the backup has actually worked on your system.
"What Are the Response Times, and When?"
Most support is business hours. That is fine for most systems. It is not fine for a member portal the night before a renewal deadline, or a store during its biggest sales week.
Ask what coverage looks like on evenings, weekends, and holidays. If you need around-the-clock coverage, it should be a defined arrangement with response targets and a direct phone number, not an assumption. The same sports-data company, when they heard that was available, gave one of the strongest reactions we have heard on a sales call:
Twenty four, seven and the phone number. Like, that's music to our ears.
At Albright Labs, 24/7 emergency coverage is a separate plan, scoped to the systems that genuinely cannot go down. Not every client needs it, and it should not be quietly priced into everyone's support. But you should know whether it exists and what it costs before the night you need it.
"What Counts as a Bug, and What Counts as a Change?"
This is where most after-launch friction comes from.
A bug is the system not doing what was agreed. A change is asking it to do something new. Reasonable people disagree about which is which, especially in the first months, when staff start using the system for real and discover things nobody thought of during the build.
Ask:
- Is there a warranty period after launch? How long, and what does it cover?
- How are bugs found after that period handled? Fixed at no cost if they were defects in the original work, or billed?
- How are changes estimated? The answer should be a clear estimate you approve before the work starts, one piece at a time, so there are no surprises on the invoice.
A developer who answers these crisply has had these conversations before and settled them fairly.
"How Does the System Stay Current?"
Software ages even when nobody touches it. Frameworks release security patches. Hosting environments need updates. Outside services like payment processors and email providers change their APIs on their own schedules.
Ask who applies updates, how often, and how they are tested before they reach production. Ask what happens when a third-party service your system depends on changes something. Ask whether updates are part of an ongoing plan or handled only when something breaks.
A system that nobody updates for two years is not stable. It is building up a large, risky update that will eventually be unavoidable.
"What Is the Undo Button?"
The CEO of one association asked this during a launch conversation, almost word for word:
Like, is there a giant undo button?
Ask about backups, how often they run, where they are stored, and when a restore was last tested. Ask how a bad release gets rolled back. Ask whether changes are tested on a copy before they reach the live system. The answers tell you whether recovery has been designed or assumed.
"What Will We Know How to Do Ourselves?"
Good support includes making you less dependent on support.
Ask what documentation you will receive, whether staff get training, and whether walkthroughs are recorded so a new hire can learn the system next year without a live session. Ask which routine tasks your team will be able to do without calling anyone. On our own projects, admin documentation and recorded walkthroughs are standard, because the person trained at launch is rarely the person using the system two years later.
"What If We Want to Leave?"
It is an awkward question to ask at the start of a relationship. Ask it anyway.
Where does the code live? Is it in a repository you own or can access? Who holds the hosting account, the domain, and the licenses for any paid components? If you move to another developer, what do they get?
The answer should be simple: it is your data, your code, and your accounts, and a new developer could pick it up with the documentation provided. Some shops tie clients to their hosting or keep the code in their own accounts. That is a choice, and it should be one you know about before you sign.
The First Few Weeks Matter Most
One more thing to ask about specifically: the period right after launch.
Most issues surface in the first few weeks, when real users with real data do things no test plan anticipated. A developer who plans for launch day and then moves on to the next project will leave you handling those issues alone. Ask what the plan is for those weeks: who is watching, how quickly fixes go out, and when the project is considered settled.
We plan for the launch and for the weeks after it, because that is when the system stops being a project and starts being something your organization depends on.
A Simple Rule of Thumb
If the proposal describes the build in detail and support in a sentence, you have been quoted a launch, not a system.
Ask the after-launch questions before you sign, while the answers are still negotiable.
Final Thoughts
The build gets the attention, but support decides the outcome. A system with a clear owner, defined response times, a fair line between bugs and changes, regular updates, a tested undo button, and a clean exit path will serve you for years. A system without those will slowly become the thing everyone works around.
You do not need a perfect support arrangement. You need a clear one, agreed before launch.
If you want clear answers to these questions for your own system, we are happy to walk through how we handle support after launch, including 24/7 emergency coverage where it is needed. Book a short consult.