Custom Software for SMEs: A Complete Guide

You are running a shop, a SACCO, a distribution business, or a growing service company - and the spreadsheets (or the borrowed WhatsApp workflow) are starting to break. The question is rarely “should we use technology?” It is “do we buy something ready-made, or do we pay someone to build software that fits how we actually work?”

This guide is the long answer. It is written for non-technical founders and managers in Kenya and East Africa who need to [VERIFY] decide between product licenses, template websites, and true custom software development for SMEs - without Silicon Valley jargon.

What “custom software” actually means

Custom software is a system built around your process: your SKUs, your member categories, your approval chain, your M-Pesa and bank flow, your bilingual receipts, your offline stores.

It is not:

• a WordPress theme with your logo
• an Excel file emailed every Friday
• a global SaaS tool you bend until staff invent workarounds

Off-the-shelf tools (POS packages, accounting suites, CRM seats) are customisable. Custom software is different: you own the behaviour, and you pay for design + build + testing + handover.

KisoByte ships both products (POS, SACCO, CRM) and custom software services. The right choice depends on how unusual your process is - covered in custom vs off-the-shelf.

When custom is worth it (and when it is not)

Build custom when at least two of these are true:

1. No product covers 70%+ of your daily workflow without painful workarounds.
2. The process is a real competitive edge (how you price, credit members, route deliveries).
3. Mistakes are expensive (wrong stock, wrong dividends, wrong invoices).
4. You will use the system every working day for 3+ years.
5. You need integrations that products do not offer (local banks, telcos, legacy ERPs).

Prefer a product or a good template site when:

• You are validating a brand-new idea and might pivot in six months.
• A mature product already matches your industry tightly (for many shops, a solid POS is enough).
• Budget cannot cover both build and ongoing maintenance.

If you are stuck between a website and a mobile app, read website vs app cost and timeline before you brief a developer.

What a real engagement looks like

Ignore the glossy “we’ll launch in two weeks” pitch. A sane custom project usually moves through:

1. Discovery - who uses the system, what hurts today, what “done” means.
2. Scope document - screens, roles, data, integrations, out-of-scope list.
3. Design - flows and UI that staff can learn without a 40-page manual.
4. Build in slices - working pieces every sprint, not a big reveal at the end.
5. UAT - your team clicks through real scenarios with real-ish data.
6. Launch - soft launch to one branch or team, then widen.
7. Support - bugfix window, hosting, and a maintenance cadence.

How long this takes depends on scope. A focused internal tool is not the same as a public app with payments and offline mode. For mobile timelines specifically, see how long it takes to develop a mobile app.

Cost: think in bands, not magic numbers

Anyone who quotes a fixed “KES X for an app” without a scope is guessing. Costs move with:

• Number of user roles and screens
• Offline / low-connectivity needs
• Payments, SMS, and banking integrations
• Admin reports and exports
• App-store releases vs internal web only
• Who hosts and who is on-call after launch

Use this planning checklist (replace numbers with your own quotes labelled [VERIFY]):

Budget item	Why it exists	Rough share of build [VERIFY]
Discovery & scope	Prevents rebuild mid-project	5–10%
UX / UI design	Reduces training and errors	10–15%
Core development	The actual product	45–60%
Integrations (M-Pesa, SMS, APIs)	Often under-quoted	10–20%
Testing & UAT support	Catches expensive bugs	10–15%
Launch & training	Adoption is part of delivery	5–10%
Year-1 maintenance reserve	Hosting, fixes, small changes	Plan 15–25% of build / year

For deeper cost questions, start with how much it costs to build a custom mobile app and hidden costs of app development.

Kenya-specific realities that change the quote:

• Connectivity - offline-first stock apps cost more than dashboard-only tools.
• Payments - STK push, reconciliation, and failed-callback handling are real work.
• Devices - many staff use mid-range Androids; design for that, not only flagship demos.
• Support timezone - a partner who disappears after 5pm UK time is a risk for Nairobi ops.

Build vs buy vs configure: a quick decision table

Situation	Lean toward
Standard retail checkout	Product POS + light config
Unique SACCO dividend / lending rules	Custom or specialised SACCO product
Marketing brochure site	Template or managed website
Customer app with loyalty + payments	Often custom mobile / web app
Internal approvals + reports on existing Excel chaos	Custom internal tool or workflow automation

“Configure” (buying a product and adjusting it) is often the best middle path. Custom is for the gaps products will never care about.

How to hire without getting burned

The Kenyan and remote freelance market is full of talented people - and full of portfolios that are templates with swapped logos. Before you commit:

Red-flag checklist

• No written scope; “we’ll figure it out as we go”
• Price far below every other quote with no explanation
• Cannot name who owns the code, hosting, and app-store accounts
• Refuses a small paid discovery or prototype milestone
• Only communicates via WhatsApp voice notes, no ticket trail
• Demo is unrelated industry and cannot walk through your scenarios
• Wants 100% payment upfront

More detail: red flags when choosing a custom software developer and questions to ask before hiring a web developer.

What good looks like

A serious partner will talk about trade-offs, maintenance, and what not to build in version one. They will introduce you to someone who will still answer the phone in month eight. If you are comparing freelancers and agencies, see web developer vs agency.

Protecting your idea and IP belongs in the contract - NDAs help, but clear IP assignment and repo access matter more. Cover that before build starts (protecting your app idea).

Website, web app, and mobile app - do not confuse them

Business owners often say “app” when they mean “something staff can open on a phone.”

• Marketing website - trust, SEO, leads. Often enough for services businesses.
• Web application - login, roles, data entry; works in a browser; can feel app-like.
• Native / store mobile app - push notifications, offline, camera/hardware; higher cost and store overhead.

Many East African SMEs should start with a responsive web app, then add store apps only if offline or push is critical. Cross-platform options (one codebase for iOS + Android) often beat hiring two native teams - see native vs cross-platform.

Social media management is not software development

Some briefs mix “build us a system” with “run our Instagram.” Those are different services and different contracts. If you need content and community management, scope it separately - what social media management services to use and our marketing services. Do not pay eng rates for caption writing, or SMM retainers for backend architecture.

Specs that save money: how to brief a developer

The fastest way to burn budget is a vague brief (“make it like Uber for x”). A usable brief for custom software development for SMEs answers:

1. Users - cashier, branch manager, HQ finance, customer - list them.
2. Jobs - the top 10 actions each role must finish in a day.
3. Source of truth - which spreadsheet or book is “correct” today?
4. Must-have integrations - M-Pesa, SMS, existing accounting, biometric clocking.
5. Offline expectations - must sales continue when fibre dies?
6. Reports - what does the owner open every Monday morning?
7. Out of scope - what you are not building in version one.

Attach photos of current forms and a sample of messy real data (anonymised). Partners who refuse to walk through that data in discovery are guessing. For communicating vision mid-project, keep how to communicate your app vision handy.

Milestone payment pattern that protects both sides

A pattern that works locally:

Milestone	What you should see	Typical share [VERIFY]
Discovery	Written scope + wireframes or clickable flows	10–15%
Vertical slice	One real workflow working end-to-end on staging	25–35%
Feature complete	Agreed scope built; UAT begins	30–40%
Launch + handover	Production live, docs, training, repo access	Remainder

Never leave “knowledge transfer” as a polite afterthought. Repo access, admin credentials, and hosting ownership belong in the contract before the final invoice clears - see what to expect in a developer contract.

Ports, phones, and “works on my laptop”

Kenya’s retail and cooperative floors are full of mid-range Androids, shared tablets, and sporadic Wi-Fi. Ask for:

• Test notes on a low/mid Android device, not only an iPhone demo
• Performance checks on 3G-class speeds where relevant
• Print / PDF fallbacks for receipts and member statements
• Clear behaviour when the API is unreachable

If the demo only works on the developer’s machine with sample data, you have a slideshow, not a system.

Maintenance: the part vendors skip in the pitch

Custom software is a living asset. Plan for:

• OS and browser updates
• Payment/API changes from banks and telcos
• New tax or reporting fields ([VERIFY] against current KE requirements with your accountant)
• Staff turnover - documentation and admin training
• Security patches

Ask every vendor: who watches the servers, what the SLA is, and what a change request costs. Long-term maintenance should be boring and scheduled - not panic WhatsApps.

A practical path for a Nairobi SME this quarter

1. Write one page: who users are, top 5 daily tasks, top 3 pains, what success looks like in 90 days.
2. Decide build vs buy using the table above.
3. Talk to two or three serious partners with the same one-pager.
4. Pay for discovery before a big build quote.
5. Ship a thin first version: one branch, one role, one happy path.
6. Measure time saved or errors reduced before expanding scope.

If you only need an honest brief reviewed, start a project brief with KisoByte. If you want product speed without reinventing retail or cooperatives, look at our software products first - then customise only the gaps.

FAQ founders ask us in the first call

“Can we start with a template and customise later?”
Sometimes. If the template becomes a tangle of plugins and undocumented hacks, rebuilding costs more than a clean custom start. Decide using custom vs template websites.

“Should everything be in one app?”
No. Version one should cover the painful path. Extra modules can wait until adoption is real - see scaling as you grow.

“Who hosts?”
Prefer clarity: your cloud account, or their managed hosting with export rights. Ambiguity here is how companies get stuck.

“How do we know the idea is worth it?”
Talk to ten real users of the process before you fund six months of build - is the app idea worth developing.

Key takeaways

• Custom software development for SMEs is justified when process uniqueness and daily usage outweigh license simplicity.
• Budget in bands with an explicit maintenance reserve; treat ultra-low quotes as risk signals.
• Scope, IP, hosting ownership, and support matter as much as UI screenshots.
• Start smaller than your ambition: a working slice beats a delayed “full system.”
• Link your next deep-dives: cost (app budget), hiring (find the right developer), and build-vs-buy (custom vs off-the-shelf).