Website Development

03

Start with the job, not the design

Before a single line of HTML, we ask one question that decides everything else: what is this website for, in the real lives of the people who will visit it? A website exists to cause an action — and the action is almost never 'look at us'. It is: find our number and call. Book an appointment. Buy this. Download this. Sign up. Trust us enough to send money or information. Every page, every paragraph, every button and every image either moves a visitor toward that action or it is decorative noise stealing their time.

• Who is the visitor, and what are they trying to accomplish at this exact moment?
• What is the single action this page should cause?
• What does the visitor need to believe before they do it?
• What objection stops them, and what removes it?
• How does this page connect to the rest of the site — and to the phone call, the booking, or the purchase?
• How will we measure whether it works — and what honest number counts as success?

This is the difference between a brochure and a business tool. The design, the architecture and the content all serve that job. The website is not the deliverable — the deliverable is the customer who acted.

04

The three languages of the web

Browsers understand exactly three languages natively, and every website in existence — every decade, every framework, every fancy feature — is ultimately built on these three. Master these and no framework can ever confuse you, because frameworks are just ways of generating these.

• HTML (HyperText Markup Language) — the structure. It describes what things are: a heading, a paragraph, a link, a form, an image, a button, a navigation menu. Good HTML is semantic: screen readers, search engines and future tools can read it. Bad HTML is divs inside divs pretending to be headings.
• CSS (Cascading Style Sheets) — the presentation. It describes how things look: colour, spacing, layout, font, animation, responsiveness at every screen size. Modern CSS can do almost anything, and it costs nothing to run — no library needed for most of what a site actually needs.
• JavaScript — the behaviour. It makes pages respond: validate a form, fetch data, update the cart, open a menu, animate a chart, talk to a server without reloading. It is the only programming language browsers run natively, which is why a huge industry — and we — build on top of it.

On top of these we add TypeScript — JavaScript with types — because when a business depends on a website, we want the computer to catch mistakes before customers do. The same discipline of typed code that runs inside our mobile apps and money systems is the discipline that runs inside our websites.

05

Sisters of the web: the supporting languages

A real website is held together by languages the visitor never sees but every engineer trusts:

• JSON — the universal format for moving data between the website and its server or API. Every API response, every config, every data payload.
• Markdown / MDX — for writing content as plain text that becomes structured pages. Blog posts, documentation, help pages — written by humans, rendered by machines.
• SQL — for the database behind the site: content, users, orders, bookings, analytics. Even a marketing site usually has a small database doing real work.
• GraphQL / REST conventions — the way the frontend asks the backend for exactly the data it needs, nothing more and nothing less.
• SCSS / CSS-in-JS / Tailwind utilities — ways of authoring CSS that keep large sites maintainable instead of a pile of conflicting classes.
• Bash / shell and YAML — the scripting that builds and deploys the site: the CI pipeline that tests, the server that answers, the config that declares it.

The point is not to impress with a list of acronyms. The point is that a website that matters is a small system, and a system has more than a front page. We choose each language for what it is best at and keep the total stack small enough that nothing hides.

06

How a web page actually loads

Before you can make a website fast, you must know what 'load' really is. It is not magic. It is a precise, repeated sequence, and every step is an opportunity to be fast or to be slow:

• You type a domain. The browser asks the DNS system: who owns this name, and what is the internet address of its server? A slow DNS answer means a slow start, before a single byte of your website is involved.
• The browser opens a connection to that address over HTTPS — the encrypted tunnel that makes every byte safe in transit. Negotiating that tunnel costs a round-trip unless it is reused.
• The browser requests the page. The server (or CDN) answers with the HTML and the headers that tell the browser how to cache, secure and render it.
• The browser parses the HTML and discovers the assets it references: CSS, JavaScript, images, fonts, favicons. Each is another request — or, if cached and well-built, answered locally in microseconds.
• The browser constructs the page: HTML becomes the document structure, CSS becomes the layout and paint, JavaScript becomes interactivity. Until enough of this is done, the visitor sees nothing.

Every one of those stages is measurable, and every one can be engineered. That is what Core Web Vitals measure; that is what a CDN accelerates; that is what pre-rendering shortcuts. A fast website is not luck — it is the product of knowing this sequence and removing everything that is not strictly necessary.

07

The architecture: choosing the right kind of site

There is no one 'correct' way to build a website — there is a spectrum, and the right place on it depends on what the site must do. We decide deliberately, and we tell you the trade-offs honestly.

• A static site — every page is pre-built to a finished HTML file. It is the fastest thing on the web, near-immune to crashes, and free or nearly free to host. Perfect for marketing sites, blogs, landing pages and company presences. This very site — the one you are reading — is a pre-rendered static site, built to be fast and ranked.
• A server-rendered site — the server builds each page on request, pulling live data. Necessary when content changes constantly: news, listings, dashboards that must be current to the second.
• A hybrid — the hard-won best of both: pre-render everything that can be pre-rendered, and let only the truly dynamic parts fetch data live. This is what modern frameworks do, and it is what we do by default.
• A single-page application (SPA) — one HTML shell that loads an interactive app inside the browser, talking to APIs for everything. Necessary for complex tools — a dashboard, a configurator, a portal — where page-reloads would destroy the experience.
• A progressive web app (PWA) — a website that installs on the phone, works offline and pushes notifications like an app, without the app store. Covered in full below — it is a first-class deliverable for us, not an afterthought.

The wrong choice is also predictable: a brochure site built as a heavy application (slow, fragile, expensive), or a complex tool built as a static brochure (impossible and glitchy). We choose architecture from the job, not from habit.

08

The modern web stack we build with

The tools change constantly, but the discipline is stable. We build on the modern stack that the best teams use — because it ships faster, runs faster, and is easier for your own team to maintain later:

• React (with Vite) — our default frontend framework. Components, typed state, and a huge ecosystem. Vite gives near-instant development feedback and production builds that are small and fast.
• TypeScript everywhere — typed code that catches mistakes at build time instead of on the visitor's screen.
• Tailwind CSS / design tokens — styling that is consistent, responsive, and designed once in a token system (colours, type scale, spacing) so every page looks like the same brand.
• Pre-rendering / static generation — the site's pages are built to finished HTML at deploy time, so the first paint is instant and search engines index real content, not an empty shell.
• Client-side navigation — after the first page, switching pages swaps only the changed part, so the site feels instant even as it stays SEO-friendly.
• Fetch / TanStack Query for anything live — the browser asks the server for exactly the data it needs, and handles loading, errors and caching honestly.

This is the stack, but it is not the story. The story is what we hold it to — core web vitals as a requirement, accessibility as a feature, security as a default, and a deploy pipeline that releases without fear.

09

Design: not decoration, direction

Design on a website has one job: to make the visitor's next action obvious and effortless. It is not 'making it look nice' — though it does that too. Good web design is information architecture you can feel: the visitor always knows where they are, what this page is for, and where to go next.

• Visual hierarchy — the eye falls on the message that matters first: what we do, who it is for, why to trust us, what to do now.
• Typographic discipline — readable at every size, on every device, without zooming or squinting.
• Generous whitespace — layout that lets the content breathe and the visitor think.
• The brand, translated — colours, mood, photography and voice that match your company, not generic stock templates.
• Mobile first — most visitors in Kenya and the world arrive on a phone. The design starts on the smallest screen and grows up, never the reverse.
• Consistency — a design system means the tenth page obeys the same rules as the first, and your team can add pages without breaking the brand.

Design decisions are measured like engineering ones. If a layout pushes fewer visitors toward the call, it is changed — by evidence, not opinion.

10

Content is the product

A website without words is a hotel with no reception. Content — copy, imagery, video, headings, meta — is where most sites win or lose, and it is exactly where most projects under-invest.

• Copywriting that sells honestly — every heading answers 'why should I care?', every paragraph earns its place, every call-to-action names the action.
• Words the customer uses — the phrases real people type into Google are the phrases we put in headings, because that is how search engines connect readers to answers.
• Structured content — titles, descriptions, headings, image text and schema so both search engines and screen readers understand the page's meaning unambiguously.
• Imagery with a job — real photos, not generic stock: a face, a product, a place. Images that load fast and earn their kilobytes.
• Multiple entry points — most visitors arrive on a specific page from Google, not through your homepage. Every page must stand alone and still make sense.

We write the initial content as part of the build, and we hand you a content system — a CMS — so your own team keeps it alive without calling a developer to change a sentence.

11

Progressive Web Apps: every website can become an app

A PWA is a website that earns app-style rights: it installs on the home screen, launches full-screen, works with no connection, and can push notifications. It is the web's answer to 'we need an app' — without the app store tax, without two separate codebases, and without waiting for approval. For most businesses, a PWA is the right first move, and we build it as the default, not the upgrade.

• A web app manifest — a tiny JSON file that declares the app's name, icons, colours and full-screen mode so the phone offers 'Add to Home Screen' and treats the site as an app.
• A service worker — the engine of the whole thing: a script the browser keeps running in the background that intercepts every request and decides what to answer from, cache or network. This is what makes offline work.
• Cache strategies — precise rules per asset: the hero image from cache instantly, the live stock-check from the network, the static app shell offline-first. Each strategy is chosen deliberately — 'cache everything' is a bug, not a feature.
• Offline-first behaviour — the defined experience when the network drops: cached pages still render, queued actions are retried when the connection returns, and the visitor is never left with a blank error.
• Background sync — a form submitted or a rent reminder sent while offline is stored and delivered automatically once connectivity returns. The visitor's action is never lost.
• Web push notifications — permission-based notifications that survive the browser closing, driven by a push service. Rent reminders, order updates, content alerts — delivered without an app store.
• Install experience — the install prompt, the launched full-screen app, the home-screen icon — designed like the app it behaves like.
• Update discipline — a PWA must not serve a stale app shell forever: versioning, cache-busting and silent refresh keep returning visitors on the current version.

The honest limit: a PWA cannot access the deepest native phone features (the camera gallery in full, background geolocation at all times, some payment APIs) the way a native app can. When the product genuinely needs those, we build the native app — and the PWA strategy we laid means the website still performs for the 90% of users who don't install anything.

12

Performance: the science of speed

Speed is not a nice-to-have. It is the measurement of respect for the visitor's time and money — and in Kenya, data costs real shillings. A site that wastes megabytes or seconds is a site literally costing customers money. And Google ranks sites by their speed, so slow sites are invisible sites.

• Core Web Vitals as requirements — LCP (how fast the main content appears, target under 2.5s), INP (how responsive the page feels to interaction, target under 200ms), CLS (how stable the layout is, target under 0.1). We measure and budget these from the start.
• Total page weight targets — we know the budget for every page: so many kilobytes of HTML, so much JavaScript, images sized and compressed to what the eye can actually distinguish.
• Pre-rendered HTML — the visitor sees real content on the first paint, not a loading spinner. This is the single greatest speed advantage a marketing site can have.
• Sensible caching — headers and service-worker rules that tell the browser what to reuse and what must be fresh, so repeat visits cost almost nothing.
• Image engineering — the right format (AVIF/WebP where supported), the right dimensions (never a 3000px image inside a 300px box), lazy loading for below-the-fold images, and descriptive alt text that doubles as SEO.
• Font discipline — two weights max, subset to the characters actually used, loaded without blocking text. Fonts are the silent performance killer no one budgets for.
• JavaScript budgets — the exact amount shipped, and nothing more: code-split per page, tree-shaken builds, and third-party scripts (analytics, widgets, chat) audited for their true cost in seconds.
• The CDN — a content delivery network serves the site from the server physically closest to each visitor, turning a 300ms round-trip across the continent into 20ms across the street.

Performance is not a test we run at the end — it is a budget we set at the beginning and defend through every change. The result is a site that feels instant because it almost is.

13

Technical SEO: engineering for Google

SEO has two halves. The half everyone talks about — keywords and content — matters, and we do it. But the half that quietly decides everything is technical: whether Google can crawl, understand and trust your site at all. No quantity of keywords helps a page Google cannot reach, cannot render, or is not sure is real.

• Crawlability — a clean sitemap.xml, a correct robots.txt, internal links that lead Google to every important page, and no content blocked behind JavaScript that won't render.
• Indexability — one canonical URL per page, correct titles and meta descriptions, no duplicate-page confusion, no soft-404s, clear 'noindex' where pages truly should not rank.
• Structured data (schema.org) — machine-readable meaning bolted onto every relevant page: Organization, Product, FAQ, Article, Event, LocalBusiness, Review. This is what earns rich results in search — the stars, the FAQ dropdown, the extra lines that double click-through.
• Rich-result eligibility — we implement the schema Google can actually promote, and validate it against Google's own tools, so the markup earns visible results rather than being decorative.
• Page speed as ranking — Core Web Vitals are Google ranking signals; a fast site is not only better for users, it is better for rankings. Same discipline, two rewards.
• Mobile-first indexation — Google ranks the mobile version of your site. A site that works on phones is not optional for SEO; it is the version Google judges you by.
• Site architecture — a logical hierarchy (home → sections → pages) with breadcrumbs and descriptive URLs, so both humans and crawlers understand where things live.
• Analytics plumbing — Search Console and analytics wired from day one, so we see how Google actually treats the site and can fix issues while they are small.

This is why we say SEO is engineering, not a spell. Titles and keywords are part of it; so are sitemaps, schema, renderability and speed. We build all of it, we verify it against the tools, and we hand you the dashboards that show it working.

14

Content SEO: the words that earn

Technical SEO gets you onto the playing field; content SEO wins the game. Google's job is to answer search queries with the best answer, and the best answer is written for humans with the structure machines can verify.

• Keyword research done honestly — the actual phrases your customers search, the intent behind them, the competition, and what you can genuinely win.
• Topic architecture — a cluster of pages around the subjects your business owns, each with a clear job, linked so authority flows from strong pages to new ones.
• Headlines that answer — the question, stated plainly, before the visitor has to hunt for it.
• Engaging, structured copy — headings, short paragraphs, lists and bold signals that are as much about scannability and comprehension as about keywords.
• Freshness — regular new content and updated pages signal an active, living business, and give search engines a reason to re-crawl.
• Local SEO for local businesses — the LocalBusiness schema, Google Business Profile alignment, and the nap-pattern (name, address, phone) consistency that lets Google trust where you are.

The honest caveat we always give: SEO compounds. It is not a one-week deliverable; it is a continuous investment whose value grows month over month. We build the machine, measure it, and keep feeding it with you.

15

Conversion: analytics, funnels and trust

A website that captures no data is flying blind. We wire analytics properly from day one — privacy-conscious, consent-aware, and honest — so you know which pages earn, which leak, and where visitors abandon.

• The funnel, defined — from landing (which page? which source?) to action (call, form, purchase, sign-up), with each stage measured so the weak link is visible.
• Events, not just pageviews — button clicks, form starts, form abandons, scroll depth, video plays, outbound clicks to WhatsApp. The pageview is the headline; events are the story.
• UTM plumbing — every campaign link tagged so you know whether the visitor came from your ad, your Instagram, your email or Google — and which actually converts.
• Goals in analytics — the conversions counted and reported on a dashboard you can open and understand, not a raw wall of numbers.
• A/B testing readiness — the infrastructure to test a headline, a button or a page against another, and let traffic decide by evidence.
• Privacy by default — consent-aware analytics (no cookies dropped before consent, no data sold, GDPR/DPO-aligned) so the site is honest as well as measurable.

Analytics is not surveillance — it is respect. It is how the company learns what its visitors need and pays for what works instead of hoping.

16

Accessibility: the open web stays open

The web's promise is that anyone can use anything. Accessibility is the engineering that honours that promise — and it is also a practical business decision: an accessible site reaches seniors, people with disabilities, people on phones in bright sun, and people with slow connections, and it ranks better for it.

• Semantic HTML — real headings, real buttons, real landmarks, so screen readers and keyboard users experience the same structure as sighted mouse users.
• Keyboard-everything — every feature reachable and operable by keyboard alone: the menu, the forms, the carousel, the modals.
• Contrast and legibility — text that passes WCAG contrast checks, at honest sizes, without forcing zoom.
• Focus states — a visible indicator of where the keyboard is, on every interactive element, on every theme.
• Alt text and labels — images described, forms labelled, icons given names, so nothing exists only for eyes.
• Reduced motion and prefers-anything — the page respects the user's system settings for motion, theme and contrast.
• WCAG 2.1 AA as the bar — we build to the standard and test against automated tools plus real keyboard and screen-reader passes.

Accessibility is not a checklist at the end. It is the default way of writing HTML, applied from the first component, so the 10th page is accessible automatically.

17

Security for websites

Most website breaches are not sophisticated attacks on impenetrable fortresses. They are exploitation of basics left undone. We do the basics absolutely thoroughly — and this is our home turf, because we run money-moving systems with far more severe requirements than any brochure site.

• HTTPS everywhere, always — every page, every asset, every API call, on a modern certificate, with redirects that enforce it. No exceptions, no mixed content.
• Security headers delivered properly — Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, frame protections — set so features silently degrade gracefully and attacks are blocked structurally.
• Forms defended — input validation on both client and server, CSRF protection on every state-changing action, rate limiting on anything that can be spammed (contact forms, logins, bookings).
• No secrets in the frontend — API keys live in environment configuration server-side, never baked into a file any visitor can download and read.
• Third-party supply chain — every script, widget, font and analytics library is audited, pinned and kept current, because a compromised widget is a compromised site.
• Updates and patching — the CMS, the framework and the plugins updated on a cadence, not when someone remembers. Most site breaches are fixes not applied.
• Backups that restore — encrypted, versioned, tested — because the operator's nightmare is not 'we lost the data', it is 'the backup doesn't work'.

The public site is the front of the shop; the same care we put behind money systems goes behind the site that represents your business. A trustworthy company has a website that is trustworthy to the byte.

18

Forms, bookings, payments and the transactional web

Most 'websites' are actually doing quiet commerce: a contact form, a booking calendar, a payment page, an order, a rent deposit, a subscription. These are transactions, and transactions have engineering requirements a brochure does not.

• Transactions that cannot double-fire — a payment, booking or submission clicked twice must happen once. Idempotency, unique keys and server-side confirmation — the same discipline our rent and bill-payments systems run on.
• Server-side verification — the form never trusts the browser; the server validates, rate-limits and records every submission.
• Payment methods that Kenya really uses — M-Pesa and Daraja rails (STK push, PayBill, B2B, B2C), Lipa na M-Pesa tills, cards, bank transfer — integrated so money moves inside the site the way the customer already pays.
• A booking or enquiry that lands in the business — the notification that reaches WhatsApp, email and the dashboard the moment someone acts, because a lead that waits is a lead that cools.
• Honest failure — a declined payment, a failed submission or an offline moment gives the visitor a clear next step, not a cryptic error and a dead end.
• Data for the operator — every submission stored, searchable and exportable, so the site is not a black box but part of the business's records.

When money moves on a website, the website stops being marketing and becomes operations. We build that transition consciously — the same ledger discipline, gateway verification and recovery paths that run our own payments platform.

When money moves through a site we build, the machinery underneath is the same whatever the frontend is:

• Initiation from a trusted server call — the payment is started server-side with a unique transaction reference, never by a promise in the browser; a double-click, a refresh and a retry all carry the same reference and are absorbed.
• Callback re-verification — the site's backend treats an arriving payment callback as a claim, queries the gateway's own status API, and only a verified ResultCode 0 marks the order paid.
• The order and the money are one transaction — purchase, booking or rent settlement and its payment land atomically, so a half-payment can never leave a half-booking.
• Rate-limited and CSRF-protected at the border — the payment form is safe on the public internet because per-user windows and origin checks are enforced before the request reaches logic.
• Exact-shortfall top-up paths — when a wallet balance is short, the site shows the exact amount needed and offers one-tap top-up, so the visitor completes in one flow instead of abandoning at the pin pad.
• Reconciliation export — the site's records match the gateway statement line-by-line, so accounts never argue with the site.

19

CMS and self-service content

A website that needs a developer to change a price or a photo will quietly go stale. We build in a content system your team actually enjoys — the right CMS for the job, from simple to headless.

• A CMS that matches the team — a clean editor for copy and images with preview and publish, without exposing them to anything fragile.
• Headless options for the big builds — content as an API, rendered by the framework, so the marketing team edits and the developers build surfaces — common, and only worth it at real scale.
• Structured fields over free text — the CMS enforces shape: prices are numbers, dates are dates, images have alt text — so the site never breaks because someone pasted a phone number into a price box.
• Drafts, revisions and approval — content changes are previewable, versioned and publishable with a button, with the safety of rollback.
• Scheduled publishing — a campaign page, a price change or a news post goes live at the right moment without a human waking up to do it.
• Everyone's browser — the editing experience works on phones too, because owners change things from where they are.

The goal is boring in the best way: updating the website becomes as routine as updating a price list, and the site stays alive because it is easy to keep alive.

20

Hosting, DNS and the infrastructure nobody sees

The prettiest website on Earth runs at zero speed if the plumbing is wrong. We take full responsibility for the invisible layer: where the site lives, how it gets there, and how it stays up under load.

• The CDN — the site's static assets and pages served from the edge, physically near every visitor, absorbing traffic spikes that would flatten a single server.
• DNS done deliberately — fast, reliable DNS with the right TTLs, configured so moves, failovers and email stay correct. DNS is where outages and hijacks both begin, and we treat it as infrastructure, not configuration.
• HTTPS and certificates — automatic, renewable, modern; a visitor should never see a security warning from a site we operate.
• Hosting that scales with intent — static and edge for content sites; managed, backed-up database and functions for anything that transacts.
• Environments that stay separate — production and staging cannot bleed into each other; a test never touches real data or real money.
• Backups with a tested restore — the recovery answer rehearsed, not invented at 2am during the outage.
• Uptime monitoring — the site checked from outside every minute, with alerts reaching the right person before visitors notice.

This layer is invisible by design, but it is the difference between a website and a liability. We operate it like the infrastructure it is.

21

How we deploy and push

A website that ships badly will break even if it is built perfectly. Deployment is a discipline, and this is the part that makes the difference between a 'website agency' and an engineering team. Here is what actually happens when we push a site live — including this one:

• Everything in version control — the entire site, from code to content config to deployment scripts, is tracked in Git. Nothing important lives only on a laptop.
• Continuous integration — on every change, the pipeline runs the type-checker, the linter and the tests automatically. A mistake is caught by the machine before a human even looks.
• Staging deployment — every change is deployed to a staging environment first: a full, real preview of the site at the new version, tested in a browser, measure-checked, link-checked.
• Pre-render at build — the site's pages are generated to finished HTML at build time, so the deployed artifact is what visitors get — no server-side surprises, no rendering dependency at runtime.
• Preview for humans — before anything touches production, you get to see and approve the real thing: the staging URL, the exact pages, the exact behaviour.
• Zero-downtime production deploy — the new build is swapped in atomically; there is no moment when the site is down, half-updated or serving a broken mix of old and new.
• One-click or one-command rollback — if anything on a live site goes wrong, reverting to the previous version is a deliberate, rehearsed action that takes seconds, not a crisis.
• Atomic asset versioning — hashed filenames mean browsers never mix an old page with new assets or vice versa. The cache cannot serve a Frankenstein build.
• The deploy record — every release is logged: what changed, when, by whom, and how to undo it. A site that can be rolled back is a site that can be improved fearlessly.

This is why we can move fast on improvements: the pipeline makes risk small, so change is cheap. Your site can be improved monthly instead of frozen in fear of breaking what exists.

22

Testing: the machine that checks every change

Good websites are not 'sold as finished' — they are continuously verified by automated tests that catch the regressions human eyes miss. Every real build ships with a test layer:

• Unit and component tests — the functions and components that drive behaviour are tested: a price calculation, a form validator, a date formatter, a component rendering the right state.
• Route and preview tests — every page renders without error, on the stack that will actually serve it.
• End-to-end browser tests — the critical journeys tested in a real browser: visitor lands → menu works → form submits → confirmation appears → the business gets the notification.
• Performance checks in CI — every build measured against the Core Web Vitals budget; a change that slows the site is flagged before it ships, not after visitors notice.
• Accessibility scans in CI — automated checks for the common accessibility failures, run on every change, keeping the bar from slipping.
• Link and SEO checks — broken links, missing meta, canonical errors and sitemap mismatches caught automatically so nothing rots silently.

The tests are not theatre and not a checkbox. They are the reason we can say 'we can change that safely' and mean it — because the machine will tell the truth before customers do.

23

Monitoring and the life after launch

Launch is a beginning, not an end. A website is alive: content changes, browsers update, security threats evolve, and traffic grows. We stay after launch with honest, measurable care:

• Uptime monitoring — the site checked from multiple locations, alerted on the first missed second, not after hours of silence.
• Speed monitoring from real users — Core Web Vitals observed from actual visitors on real devices, so we catch the slowdown real conditions cause, not only the happy lab.
• Error and crash views — broken assets, failed requests and runtime errors surfaced to the operator with the detail to fix them.
• Security patching — the framework, the dependencies and the platform kept current on a cadence, with the fix verified in staging before it reaches visitors.
• Content health — broken links, expired certificates, and stale pages flagged so the site that impressed yesterday cannot quietly decay today.
• The work log — what was changed, when and why, so both sides always know the site's real state.
• Growth support — when you need a new page, a new section, a new language or a new feature, the pipeline makes it a routine, safe, fast release.

Most website projects end at launch and the site rots. Ours continue because the site is part of your company — and a part of your company stays maintained.

24

Internationalization: one site, many languages

For businesses serving more than one language — and Kenya genuinely is one — the website should serve each audience in the language they think in, with the technical structure search engines understand for each.

• URL structure that is correct — the per-language routes (with hreflang annotations) that tell Google these are translations of one page, not duplicates competing against each other.
• A translation workflow, not translation chaos — editors translate in the CMS with preview, a glossary for brand terms, and no engineer required for content in the second language.
• Design that survives translation — layouts tested for the longer German sentence, the shorter Swahili phrase, right-to-left where it ever applies — because text length changes and designs must not break.
• Numbers, dates and money done locally — the currency, the date format and the phone-number format rendered the way each audience expects, from one source of truth.

A multi-language site done properly is not two sites — it is one engineered site serving many audiences, and the engineering is in the structure, not the copying.

25

What a website build actually looks like with us

The process is visible, honest and ends with you owning everything. It looks like this:

• 01 · The job — we agree what the site must do, who it serves, what success looks like, and what it must never sacrifice.
• 02 · The plan — the pages, the structure, the content outline, the design direction and a budget you can defend to anyone.
• 03 · The design — the visual language and the first real pages, in your brand, on your real content — reviewed on a phone and a desktop.
• 04 · The build — real pages, real content, real components, in sprints you can see and click as the site takes shape.
• 05 · The engineering — performance budgets, accessibility, SEO structure, security headers and the deploy pipeline, built in the code, not bolted on after.
• 06 · The preview — the staging site, the exact thing, reviewed by you, tested by the machine, measured against the budgets.
• 07 · The launch — the zero-downtime deploy, the DNS cutover, the search engines told (Search Console, sitemap), the analytics verified live.
• 08 · The life — monitoring, updates, content support and measurable growth, as long as the site lives.

You own the domain, the code, the content and the accounts. Every credential, every platform, every byte — handed over in full. No lock-in, no hostage files, no mystery.

26

Honesty about limits

We are honest where most agencies sell dreams, because trust is the whole point of a website:

• A website does not instantly rank. SEO compounds over months; anyone promising page-one in a week is selling something that will not be delivered.
• Design does not fix a weak offer. The site makes a good business clearer; it cannot manufacture value where there is none.
• A website is not an app. If the product genuinely needs device-level power — the camera gallery, full offline background work, deep push — we will say so, and build the native app when it is justified.
• Cheap is not a discount. The fast, unbreakable, ranked, maintained site is not the same product as the template with a logo slapped on. We quote the real one.
• You own it all at the end. The code, the data, the accounts and the decision rights — always.

Honest scoping is the first deliverable, because a website you understand is a website you trust — and trust is the entire transaction the site exists to perform.

27

Web applications: the software under the pages

A website tells the world who you are; a web application does work — it is software that lives in a browser but behaves like a dashboard, a portal or an operator tool, not like a brochure. The manager's workbench she opens every morning, the client portal customers sign into, the tool a support team runs on — these are web applications, and they deserve their own engineering, which is exactly what we count as part of web development.

• They feel like software, not documents — navigation is a workbench, lists are alive, actions are instant, and the interface is dense the way a serious tool is dense.
• They are built around logged-in people — sessions, roles, permissions and ownership decide what each person sees and does, on every screen, server-side.
• The data is the product — records, statuses, histories and teams; the interface is how people command and read that data.
• They talk to an API — the app is a client of its own backend, so the same data can also serve a mobile app, a desktop app, an admin tool and external integrations.
• They share one source of truth — a tenant paying on the phone sees the same transaction the landlord sees in the dashboard, because both read the same records.

The boundary is real but the foundation is shared: a web application is built with the same languages, the same servers, the same security and the same deployment discipline as a website — it just wraps them in a working product instead of a presentation.

28

Dashboards, portals and operator tools

Most companies' real daily software is invisible: the dashboard, the portal, the queue. These are the surfaces where business actually gets decided, and we build them as first-class products — not as an afterthought called 'admin'.

• Dashboards that respect a busy morning — the state a manager needs at a glance, the exceptions that need the eye, and the one action most likely next.
• Portals for customers and partners — the client's window into their own data: balances, bookings, documents, invoices — succeed where the relationship grows.
• Operator tools for queues and desks — the support agent, the cashier, the dispatcher: keyboard-fast, calm at high volume, tolerant of mistakes.
• Roles and permissions that mean it — owner, manager, member, viewer — enforced in the backend so hiding a button is never the real protection.
• Heavy data that stays calm — virtualized tables with hundreds of thousands of rows, pagination that does not lose your place, filters and search that answer instantly.
• Audit trail for who did what — operator actions logged and attributable, because an accountable tool is a safer business.

The difference we hold these to: a dashboard is not a report that updates. It is a living surface — the moment somebody changes the data, the screen already knows. That is what makes it software.

29

Realtime: the screen updates itself

A stale screen is a lie the tool tells the operator. When the database changes — a payment arrives, a ticket is assigned, a stock level drops, a colleague edits a record — the web application should reflect it without anyone pressing refresh. We build realtime as a first-class capability, not a vendored widget.

• Live subscriptions on the data that matters — the app asks the server to push updates for the exact records on screen and subscribes to them; the channel replaces polling, not bolting on top of it.
• WebSockets where the connection must be immediate and bidirectional — chat, presence, shared editing, dashboards that never lag — a persistent, reliable connection instead of repeated requests.
• Optimistic UI with honest rollback — the interface applies the user's intention instantly, then reconciles with what the server actually accepted; on failure it apologises and offers the rescue, never silently dropping data.
• Presence: who is here and what they are doing — typing, viewing, online/offline — the difference between collaborative software and a solo tool wearing a group costume.
• Reconnect that resumes, not replays — when the network drops, the app reopens where it stopped, resubscribes, and only syncs what changed, so a flaky connection feels like a stable one.

Realtime is not the flashy part — it is the honest part. A web application that updates itself is telling the operator the truth about the business as it happens.

30

State, roles and multi-tenant workspaces

Two things separate a web application from a decorated website: state (what the app remembers while it works) and authority (what each person may do with it). Both are engineered deliberately, not assembled from libraries.

• State management with a spine — the frontend keeps a typed, predictable store of what the current session knows, so screens agree with each other and with the server; no 'two screens, two truths'.
• Server cache as the source of truth — the data layer asks the backend for exactly what it needs and keeps it fresh, with loading and error states surfaced honestly instead of guessed.
• Roles and permissions decided server-side — owner, admin, manager, member, viewer, tenant — every action checked against the actor's role and the record's ownership, not against the visible UI.
• Multi-tenant workspaces — one product serving many organisations, each with isolated data, its own settings, its own seat limits and its own billing, sharing one codebase instead of a hundred copies.
• Feature flags per workspace — roll the new feature out to the tenants ready for it, test with one, and stage the rest — never a company-wide surprise release.
• Audit on the decisions — who granted whom which role, who changed which record — the machine that makes permissions accountable.

A web application without these is a brochure with a login page. With them, it is the operational spine of the business — which is what a serious product should be.

31

Offline-tolerant editing and sync

Kenyan connectivity deserves a product designed for it: the network exists, but it is not guaranteed, and operations cannot stop because it did. Web applications we build hold the state locally, keep working through outages, and synchronise cleanly when the connection returns.

• Local-first storage — the app keeps a working copy of what the operator is doing, so an outage pauses the network, not the work.
• A queue for everything the user does — edits, creates, submissions and sign-offs accumulate locally and push when connectivity returns; nothing is lost to a drop.
• Idempotent, safe sync — each operation carries its own identity, so retrying after a partial failure never duplicates a record, never double-charges a payment, never splits an order.
• Conflict handling that is honest — when two people edit the same thing offline, a defined rule decides who wins, and the loser is told — not silently overwritten.
• Background retry with clear status — pending, syncing, synced, conflicted — the operator always knows where their work stands, and retries happen automatically.

This is the same discipline our money systems run: the network is a feature, not a precondition. The product works when the network is perfect and still works when it is not — because the business never stops either way.

32

When a website becomes more than a website

Almost every website project, while it is being built, reveals the same truth: the company needs more than pages. It needs an appointment system, a booking engine, a client portal, a dashboard, an online store, a realtime notice board, a rent-collection point, an internal team tool. We build websites as the surface of systems on purpose — and when the site's success creates the need for a web application, a portal or a native app, we build that too, on the same foundation, so nothing is thrown away.

The website is not the ceiling. It is the front door of a building the company will keep growing — and we build front doors that hold the weight of what comes next.

The toolchain

The website toolchain

Every layer below is chosen from production experience — not fashion. These are the tools and practices that build fast, ranked, secure, maintainable websites, and they are the exact tools running this site you are reading.

Lifecycle

The website lifecycle — from blank page to living system

A good website is not a one-time deliverable. It is a company representative that has to load fast, rank, convert, stay secure and keep telling the truth — for years. This is the lifecycle we run every site through.

Closing

More than development

Websites are how most companies meet most of their customers for the first time. We build that meeting to be fast, honest and effective — and to keep being so for the life of the company. That includes:

A website is the front door of a company, and every visitor is a customer deciding in minutes whether to walk in. We build front doors that open fast, open honestly and keep that promise every day the company is alive.

We build websites the way we build money systems — because in Kenya, a website that collects rent, accepts bookings or takes payments is money systems. Every byte, every click and every shilling is held to the same standard as the software we run ourselves.