Most businesses do not lose money on websites because they picked the wrong platform. They lose money because they bought a quote instead of a capability. The site launches, it looks reasonable, and then nobody can change a price, nothing ranks on local search, and the phone number baked into the hero image is six months out of date.
Start with the outcome, not the stack
Before you compare a single proposal, write down what the website has to do for the business — with a number attached. "Get more bookings" is not a requirement. "Receive 15 enquiries a month from Google and WhatsApp at a cost per enquiry under KES 500" is. When you write requirements that specific, half the quotes disqualify themselves in the first conversation, and the survivors are actually worth comparing.
Ask how they work before you ask what it costs
Delivery answers tell you more about outcomes than a price list does. Ask every candidate the same things, in the same order, and write the answers down.
- Who exactly will work on my project? Names, roles, and whether they are employees or subcontractors.
- Can I speak to a client with a project like mine? Not a logo wall — a reference who will describe what went wrong as well as what worked.
- What do the first two weeks look like? If week one is "we start designing", you are being sold pixels, not outcomes.
- How is content handled? Who writes it, what happens when it is not ready at launch, and who proofreads the final copy.
- What is your defect window? Thirty days of bug fixes after launch is normal. Ninety days of free feature work means the scope was priced wrong.
- Who owns the code and the accounts? Domain, hosting, analytics, Search Console, CMS admin, design files.
- What does support cost after launch? Hourly, monthly, or nothing. "Nothing at all" is an answer.
Ask about the work, not the tools
Technology choices matter only where they change your outcome. Questions that separate serious candidates from the rest:
- Will the site load in under three seconds on a KES 15,000 Android handset on 3G? Have you measured it, or only looked at it on a laptop?
- How will M-Pesa payments work here — STK Push, redirect, or a till number? Who holds the Safaricom account?
- What happens to my content, domain, and customer data if we stop working together tomorrow?
- Which parts of this site are custom code, and which could my own team edit?
- How will search engines read this site, and what will you set up so I appear for the searches my customers actually make?
- What will you hand over at the end, and in what format?
Red flags that should end the conversation early
- Quoting without asking a single question about your business, your customers, or your competitors.
- A price with no scope attached — no page list, no feature list, no exclusions.
- "Unlimited revisions" or "unlimited pages" in writing.
- Registering your domain later, or in the agency's name, so the first site can launch this week.
- Showing you other clients' projects but not a live URL you can open yourself.
- 100% payment before any design or build work exists.
- Vague answers about who does the work, dressed up as phrases like "our partner network".
- A proposal that is a PDF of screenshots with no written scope at all.
Understand what you are actually paying for
A quote should be a breakdown, not a number. If nobody can tell you where the money goes, the number is a starting position in a negotiation you have not noticed yet. Honest breakdowns separate design, engineering, content, integrations, and ongoing costs — the same four cost levers we use in what a website actually costs in Kenya in 2026. Two things quietly inflate every quote: a brief that says "make it modern and professional", which produces a design budget nobody can verify, and a scope that omits content, which then becomes half the build.
Read the contract for these seven clauses
- Ownership. Code, design files, and content become yours on final payment, stated in writing.
- Accounts in your company name. Verify the domain registration before the second instalment, not after launch.
- Scope with exclusions. What is included, what is explicitly not, and what triggers a change request.
- Milestones tied to deliverables. Never more than 40% upfront, with the balance on handover after you accept the site.
- Support terms. What is covered, for how long, at what response time, and at what rate afterwards.
- Handover. Source code, credentials, documentation, and a walkthrough with the people who will use it.
- Exit clause. What you may take with you, and in what format, if the relationship ends early.
The Kenyan-specific questions most buyers skip
- Who holds the Safaricom Daraja account? Production credentials must live with your business, not the agency. Sandbox testing is not go-live testing.
- What is your position on the Data Protection Act? Consent, retention, and where customer data physically sits all matter under active ODPC enforcement.
- Where is the site served from? Local hosting versus offshore CDN changes latency and data residency.
- How was it tested on real devices and real networks? A Tecno or Infinix on 3G is your actual customer.
- Who supports it when you are open and they are not? Kenyan business hours span Nairobi to Lamu.
- Can your team support it in Swahili? Not every page needs it, but onboarding and support usually do.
Get three quotes and compare them the same way
Ask each candidate for the same deliverable in the same format: a scope list, a line-item breakdown, a timeline with milestones, and a support proposal. Then score them identically. Do not compare a KES 180,000 proposal against a KES 900,000 one on price alone — they may be pricing different products, and the cheaper one may simply be missing the things that decide whether the site works.
What a proper handover looks like
- Source code and design files in your own repository or storage, with history
- Domain, hosting, DNS, CMS, analytics, and Search Console accounts owned by you
- A document explaining how to publish a page, add a service, and change a price
- A training session with the people who will actually use it
- A support window with a named contact and a stated response time
- A visible backup and update routine, including who holds the credentials
A scoring rubric you can use today
- Quality of their questions about your business (0–10)
- Quality of relevant work, verified on live URLs (0–10)
- The team who will do the work, and their availability (0–10)
- Contract and ownership terms (0–10)
- Three-year total cost of ownership, not just the build price (0–10)
The cheapest quote is usually the most expensive option once you count a site nobody can update, nobody can find, and that cannot take a payment. Choose a team that can explain what your website must do for the business, show you work you can verify, and hand you the keys when it is done. If you want that conversation, here is what a business website should include before you sign anything, and we are happy to walk through it with you.
Build what comes next
Want to explore what these ideas could mean for your business? Start a conversation with our team.
