Launching a website should not leave you wondering who fixes a problem the next day. Every fraxBIT project includes 30 days of bug support after delivery: if something in the agreed build does not work as it should, we fix it. New pages, new features or changes to how something works are new work, so we discuss and price them separately. We make that difference clear before the project starts, so nobody has to find out in the middle of a problem.
Why this matters on launch day
The first days after a launch are when real people start using your site: on phones you never tested, with forms they fill in their own way, through links shared in places you did not expect. Small issues tend to show up here, and that is normal.
What is not fine is the uncertainty. If a contact form stops sending on day two, you should not have to wonder whether your developer will pick up, how long it will take or whether you are about to receive an invoice. That question should be answered before you sign anything.
Bug fixes vs new work
The line between the two is simple once you write it down. A bug is something that does not work the way it was agreed and built. New work is anything that changes or adds to what was agreed.
| Covered as a bug fix | New work, discussed and priced separately |
|---|---|
| The contact form does not send or arrive | Adding a new service page |
| A page breaks or overlaps on a common phone size | Redesigning a section you have already approved |
| A link or button goes to the wrong place | Changing how a booking or checkout flow works |
| A feature in the agreed scope throws an error | Connecting a new tool, CRM or payment provider |
| Content in the build displays incorrectly | Writing new content or translating the site |
Neither side of the table is bad news. New work is usually a good sign: the site is live, you have learned something from your visitors and you want to build on it. It just deserves its own conversation about scope, timing and price, instead of being squeezed in as a "quick fix".
What to agree before the project starts
Most post-launch arguments come from things nobody wrote down. Whoever builds your website, make sure you know the answers to these before work begins:
- How long is support included after delivery, and from which date does it count?
- What counts as a bug and what counts as a change? Ask for examples, like the table above.
- How do you report a problem, and how quickly can you expect an answer?
- What happens after the support period: ad hoc fixes, a monthly plan or nothing at all?
- Who owns the accounts: domain, hosting, analytics and any paid tools should be in your name or transferable to you.
If the answers are vague, ask again. A good studio will be glad you asked, because clear expectations protect both sides.
How to report a bug so it gets fixed fast
A good bug report saves a lot of back and forth. Include:
- The page where it happens, with the full link.
- What you did, step by step, and what you expected to happen.
- What happened instead, with a screenshot or a short screen recording.
- The device and browser, for example "iPhone 15, Safari" or "Windows laptop, Chrome".
- Whether it happens every time or only sometimes.
"The form is broken" can take a day to track down. "The quote form on /contact shows an error after I press Send on my iPhone, screenshot attached" is much quicker to find and fix.
After the 30 days
Websites are not finished on launch day. Content needs updating, plugins and frameworks get new versions, and your business changes. If you want ongoing help, we can talk about what you actually need, whether that is the occasional update, regular improvements or a bigger next phase. You decide, based on how you use the site, not on a package someone else picked for you.
Whatever you choose, the principle stays the same: you should know what is covered before you need it, not find out during a problem.
Need help with your website? Just send us an email or tell us about your project.
Furdui Alex-George