Every few months someone asks why a technology consultancy bothers building its own products. The question usually comes with an assumption attached: that products are where the glamour is, and that a consultancy building one is chasing a bigger idea than client work allows.
At CloudNala the reasoning runs the other way. The products we build are deliberately unglamorous. TenderCity helps South African suppliers find and qualify government tenders. FleetNala helps small fleet owners capture fuel slips, driver requests and vehicle costs through WhatsApp. DevNala turns engineering activity into delivery insight for software teams. None of them is a moonshot. Each one exists because we kept meeting the same operational problem, week after week, in businesses that had no good tool for it.
This series is about building a modern technology business: how we choose what to build, how we use AI without handing over accountability, how we think about coding tools, how research becomes reusable work, and how a small business can run an AI-assisted operation without losing control. It starts here, with the case for boring software.
This series describes how CloudNala works. Where examples involve other businesses, they are fictional and their details are illustrative. We make no claims about client results.
What "boring" means here
A boring product, in the sense we mean, solves a problem that has four properties.
It recurs. The problem happens every week or every month, not once. A supplier looks for tenders every week. A fleet owner reconciles fuel money every week. A recurring problem creates a recurring reason to use the product and to keep paying for it.
It has a narrow buyer. One kind of person feels the pain and can decide to fix it. The owner of a small transport business, the bid manager at an engineering firm, the head of engineering at a software team. A product that needs five departments to agree before anyone can buy it is a consulting engagement wearing a product's clothes.
Its value can be measured. The buyer can see whether the product helped: fewer missed tenders, reconciled fuel spend, shorter review cycles. A product whose value is "better visibility" with no measurable outcome struggles at renewal.
It can be implemented the same way each time. Onboarding the tenth customer looks much like onboarding the second. If every customer needs a bespoke project, the business is a services firm with a code base, not a product company.
An idea that fails one of these gates is not necessarily a bad idea. It may be a perfectly good consulting engagement, or a feature of something larger. It is not yet a product, and treating it as one burns time and money.
Why recurring operational problems are good businesses
The problems that fit this test tend to sit inside ordinary operations: compliance, reconciliation, scheduling, documentation, reporting. They are rarely exciting to talk about. They are also where small and mid-sized organisations lose the most time, because large-enterprise software is too expensive and too complex for them, and spreadsheets and messaging apps are what they use instead.
That gap is particularly wide in South Africa. Many businesses run critical processes on WhatsApp, email and spreadsheets because those tools are available, familiar and cheap. A product that meets people in the tools they already use, rather than demanding they adopt a new platform, has a much lower barrier to adoption. FleetNala's choice of WhatsApp as its primary interface is a direct consequence of that observation: fleet drivers already send slip photos and money requests on WhatsApp, so the product starts there.
We have written about the general principle in Good AI agents meet users where they already work, and about the tender problem specifically in How we built TenderCity.
The implementation loop is the business
A product company that serves small and mid-sized organisations does not win by having the most features. It wins by making each implementation easier than the last.
Every early implementation teaches something. Some steps turn out to be the same for every customer: setting up categories, importing a supplier list, configuring a WhatsApp number. Others turn out to be genuinely different. The repeated steps are candidates for product features, templates or automation. When they are built, the next implementation is shorter, cheaper and more reliable.
This loop is also why a consultancy is a reasonable place to build products. Client work exposes us to the same operational problems repeatedly, across sectors. The products are, in part, the distilled pattern of that exposure. And the products, in turn, make our advisory work sharper, because we live with the consequences of our own architecture and support decisions every day.
What we deliberately avoid
A boring-product strategy is as much about what not to build.
Platform ambitions too early. It is tempting to build a general platform that could serve many problems. In practice the general platform rarely serves any one problem well enough to be bought. We start narrow and widen only when customers pull us.
Features that only demonstrate well. An AI feature that impresses in a demonstration but is not used in the weekly workflow adds cost and support burden without adding value. Each feature has to earn its place in the recurring task.
Bespoke work disguised as product. When a prospective customer asks for something only they need, we either decline it, price it as services, or wait to see whether a second and third customer ask for the same thing.
Unmeasured value. If we cannot say how a customer would know the product helped, we have not understood the problem well enough yet.
How AI changes the economics
AI has changed the cost of building software, and that makes the boring-product discipline more important, not less. When code is cheaper to produce, more products get built, and the constraint shifts from building to choosing well, implementing well and supporting well. We discussed this shift in Buy, build or grow? Rethinking procurement when code is cheap and in Keeping systems fit.
For a small product company, AI helps in specific places: extracting structured data from messy inputs such as fuel slips or tender documents, drafting summaries for a human to check, and reducing the manual effort of each implementation. It does not replace the need to choose a recurring problem, understand a narrow buyer and measure value. A product built on cheap code around an unclear problem is still an unclear product, only produced faster.
What boring products demand from the business
Choosing an unglamorous problem does not make the work easy. It moves the difficulty into places that are easy to underestimate.
Support becomes part of the product. A small fleet owner whose driver cannot submit a slip on a Saturday morning does not care whether the cause is the product, the phone or the network. Support for operational products has to be fast, plain and available when the operation runs, which is often outside office hours.
Pricing has to match how the buyer thinks. A small business budgets monthly and in rand. A price that varies unpredictably with usage, or that is quoted in dollars, creates anxiety the product cannot overcome. Where a product depends on services priced in dollars, such as AI models or cloud infrastructure, the business carries that exchange-rate risk rather than passing it straight to the customer.
Reliability matters more than novelty. An operational product is used every week, so every outage is noticed. A feature shipped late is forgiven; a weekly task that fails is not. This is the same reliability-first argument made for large organisations in our South African Enterprise AI in Practice series, applied to a small product company.
The roadmap is set by repetition, not by ambition. Features are prioritised by how often customers hit a problem, not by how impressive the feature would be. That discipline is less exciting than a vision statement and considerably more useful.
These demands are why boring products tend to be durable once established. The competitors who arrive later have to match not only the features but the support, pricing and reliability the incumbent has learnt the hard way.
A test for your own product ideas
The same four gates work for anyone weighing a product idea, whether a founder, an internal innovation team or a consultancy considering productising a service.
| Gate | Question | Warning sign |
|---|---|---|
| Recurrence | How often does the buyer face this problem? | "Once a year" or "when something goes wrong" |
| Buyer | Who feels the pain and can decide to pay? | A committee, or nobody in particular |
| Value | How would the buyer know it helped? | "Better visibility", "digital transformation" |
| Repeatability | Will the tenth implementation look like the second? | Every customer needs a different configuration project |
If the idea passes all four, it may be a product. If it fails one, that is useful information: it tells you what to learn next, or whether to deliver the idea as a service instead.
The point of view
Durable technology businesses are more often built on recurring, unglamorous problems than on big ideas. The discipline is to choose problems that recur, serve a narrow buyer, deliver measurable value and can be implemented the same way each time, and then to make every implementation easier than the last. AI lowers the cost of building. It does not lower the cost of choosing badly.
Next: Part 2, How we use AI to produce client work without handing over accountability. All parts are on the series page.
How CloudNala can help
We help founders, product teams and service businesses test product ideas against these gates before they commit build budget: clarifying the recurring problem and the buyer, defining how value will be measured, and designing an implementation approach that can repeat. Where an idea passes, we help shape and build the first version; where it does not, we say so.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Talk to CloudNala or write to us at consult@cloudnala.co.za