Why Desishub · Pillar 02 of 03
Fast at any scale, online or offline
Measured on the phones and networks your customers actually have, not on a developer's laptop
A system that is quick in the office and unusable in a shop in Nakawa has not been tested. This page sets out how we measure performance before launch, what we target, what our uptime figure actually means, and how our tills keep selling when the connection goes.
Facts on this page last verified 6 November 2026
- Written scope before you pay
- A working demo every Friday
- You own the code
What we measure, and what we tell you
Before launch we agree the numbers that matter for your system and the conditions they are measured under. That usually means a Lighthouse performance target for anything a customer loads in a browser, a 95th-percentile latency target for the API, and a concurrency figure the load test has to survive. Those go in the scope document, so performance is a deliverable rather than a hope.
After launch, the systems we host are monitored by external checks at one-minute intervals. That is where the 99.9% figure comes from, and it covers a rolling twelve months of uptime across hosted client systems, excluding windows the client asked us to take the system down.
Offline-first, explained
In a Kampala shop the connection drops. If the till stops, the business stops, so for point-of-sale and field systems we do not treat the network as available. The desktop app keeps a local mirror of the data it needs to sell — products, prices, stock — and every write it makes goes into an outbox. When the connection returns, the outbox replays in order and the server reconciles it.
That design has consequences we handle explicitly: what must never be queued (anything that needs a server-side authority check, such as a credit limit), how conflicts resolve when two branches edited the same record, and what a cashier sees while the system is behind. Those rules are written down per project, not improvised.
The profiler is ours, and it is published
Pulse is our application profiler and N+1 query detector, open source and the same tool we point at a client's slow endpoint. You can read what it measures rather than take our word for what it found.
When a system is already slow
If you have a system that has become unusable, the first thing we do is measure it, not quote a rewrite. Profiling usually finds the same handful of causes: a query running once per row on a list page, a missing index on a column that every filter uses, an unbounded page returning thirty thousand records, or an image pipeline serving originals. Those are hours of work, not months. If the architecture genuinely cannot carry the load, we will say so and show you the measurement that proves it.
Our own site
We hold this site to the same standard we sell. It is a Next.js application that renders on the server, ships deferred JavaScript for anything below the fold, and is tested on throttled mobile hardware. If you want to check our numbers rather than take them, run Lighthouse against this page yourself — that is the point of publishing the conditions.
Related: the security and design pillars, and Grit, the framework our backends are built on.
Why teams pick us
How we make it fast, and prove it
- 01
Load tested before launch, not after
k6 against real endpoints at your expected peak concurrency plus a margin. You see the results, including anything we had to fix to pass.
- 02
Profiled, not guessed
We use Pulse to find N+1 queries and slow paths in our Go backends. Most 'slow app' problems are a missing index or a query running once per row.
- 03
Measured on a mid-range Android
Lighthouse 90+ at launch over throttled 4G on real low-end hardware, because that is the device most Ugandan visitors are holding.
- 04
Offline-first where it matters
Tills, clinics and field apps hold a local copy and queue their writes, then reconcile on reconnect. Shoppleet runs this way across 50+ branches.
- 05
Built on an edge we control
Cloudflare for caching, DNS and DDoS protection; Redis for hot reads and queues; Postgres tuned with the indexes the load test asked for.
- 06
An uptime figure with a method
99.9% uptime across hosted client systems, measured by external checks every minute over a rolling twelve months. The method is published because a bare number is not evidence.
FAQ
Frequently asked questions.
01What performance do you actually commit to?
For a marketing site or web app we target a Lighthouse performance score of 90 or better at launch, measured on a mid-range Android over a throttled 4G connection, because that is what most Ugandan visitors are holding. For an API we target a 95th-percentile response under 300ms at the concurrency we load-tested. We write the target and the measurement conditions into the scope, so you can hold us to it.
02What does your 99.9% uptime figure mean?
It is the rolling twelve-month availability of client systems we host and monitor, measured by external HTTP checks at one-minute intervals, excluding maintenance windows the client scheduled. We state the method because an uptime number without one is marketing.
03Do you load-test before launch?
Yes. We run k6 against the real endpoints at the concurrency the client expects at peak, plus a margin, and we profile what the test exposes rather than guessing. Most of what we find is database work: a missing index, or a query running once per row instead of once per page.
04What happens when the internet drops?
For point-of-sale, clinics and field data collection, the system keeps working. The app holds a local copy of the data it needs and queues the writes it makes, then reconciles when the connection returns. Shoppleet tills run this way across more than fifty branches.
05Our current system is slow. Can you fix it without a rewrite?
Usually, yes, and we will tell you before taking the work. We start by measuring rather than rewriting: profile the slow paths, find the N+1 queries and missing indexes, add caching where it is safe. A rewrite is the last option, not the first bill.
06Will the site be fast on a cheap phone on a weak network?
That is the only test that matters here. We test on real low-end Android hardware over throttled connections, not just on a developer laptop. Images are sized and served in modern formats, pages ship as little JavaScript as the feature allows, and content renders from the server so it is readable before scripts finish.
Ready to grow your business in Uganda?
Desishub Technologies is the partner you need for world-class web design and custom software development.