Simplicity vs Enterprise: Building Software for Both Corner Shops and Retail Chains

If you’ve ever built software for businesses, you’ve faced this dilemma: small businesses want simplicity while enterprises want control. Build for one, and you lose the other.

This is the story of how we navigated this challenge while building Sokosuite, a POS and inventory system for Kenyan retailers—from the smallest duka (corner shop) to multi-location retail chains.

The Classic Problem Every B2B Software Builder Faces

Small businesses want simplicity. They don’t have time for training, don’t want to click through five screens to do one thing, and will abandon your product the moment it feels “too complicated.”

Enterprises want control. They need approval workflows, audit trails, role-based permissions, and the ability to configure everything. They’ll reject your product if it feels “too basic.”

Build for both poorly, and you get a Frankenstein product that frustrates everyone.

The Kenya Context: What’s a Duka?

In Kenya, a duka is the backbone of retail. These are small, often family-run shops found on nearly every street corner. They sell everything from cooking oil and sugar to phone airtime and eggs. Most dukas:

• Have a single owner who is also the cashier, stock manager, and accountant
• Buy inventory with cash from wholesalers or local markets
• Don’t track inventory formally—they reorder when shelves look empty
• Have customers who buy on credit (deni) and pay later
• Process 50-200 transactions daily, mostly cash and M-Pesa

On the other end, Kenya also has growing retail chains and wholesale distributors who need:

• Purchase order workflows with supplier approvals
• Goods Received Notes (GRN) with batch tracking and expiry dates
• Stock transfers between locations
• Formal stock takes with variance reconciliation
• Multi-user permissions with audit trails

One country. Two completely different operational realities.

The Temptation: Build Two Products

The obvious solution is to build two separate products:

1. Duka Lite — Simple, stripped-down, mobile-first
2. Duka Enterprise — Full-featured, complex, desktop-oriented

Many companies do this. It’s safe. It’s clean.

But it’s also:

• Expensive — Two codebases, two teams, two roadmaps
• Limiting — What happens when a duka grows? Do they migrate to a new product?
• Fragmented — Features built for enterprise never benefit small users, and vice versa

We chose a different path: one product with progressive complexity.

The Design Philosophy: Simplicity by Default, Complexity on Demand

Our guiding principle became:

The simplest path should be the default. Complexity should be available but never forced.

This manifests in three concrete patterns.

Pattern 1: Multiple Paths to the Same Outcome

Consider adding stock to inventory. An enterprise needs:

Supplier Setup → Purchase Order → Approval → Send to Supplier →
Goods Received Note → Batch Entry → Expiry Tracking → Stock Update

A duka owner who just bought 10 bags of sugar from the wholesale market needs:

"I have 10 bags of sugar. They cost me 180 KES each."

Both are valid. Both should be supported. We built both.

Enterprise Path: Full Purchase Order → GRN workflow with line items, approvals, package-to-unit conversions, batch numbers, and expiry dates.

Duka Path: A single “Quick Add Stock” dialog with three fields that matter. Done in 30 seconds.

The enterprise workflow still exists—it’s just not in the duka owner’s face.

Pattern 2: Smart Defaults That Match the User

When a new tenant signs up, we don’t ask them to configure 47 settings. Instead:

• Simple Mode: ON by default
• Customer field: Hidden (dukas serve walk-in customers)
• Payment methods: Cash + M-Pesa (the reality of Kenyan retail)
• Discounts: Enabled, max 100% (owner decides)
• Keyboard shortcuts: Enabled (power users discover them)

Enterprise users can toggle Simple Mode OFF and unlock advanced dashboards, full procurement workflows, and multi-store management.

The key insight: defaults are a form of product opinion. By choosing duka-friendly defaults, we signal that small businesses are first-class citizens, not afterthoughts.

Pattern 3: Progressive Disclosure in the UI

Complex features exist but stay hidden until needed. The duka owner never sees “Batch Number” or “Expiry Date” fields unless they expand Advanced Options. The enterprise user knows to look there.

Case Study: The Egg Problem

Eggs perfectly illustrate the complexity gap between dukas and enterprises.

Duka Reality:

• Buy a tray of 30 eggs from the market
• Sell individual eggs, half trays, or full trays
• Simple pricing at each level

Enterprise Reality:

• Purchase Order: 100 trays from Supplier X
• GRN: Received 98 trays (2 rejected - cracked)
• Batch: TRY-2026-001, Expiry: 2026-02-15
• Stock: 2,940 eggs (98 × 30)
• FIFO: Sell oldest batch first
• Catalog: 3 items (single, half, full) all pulling from same inventory

Our Solution: Inventory-Catalog Separation

We created two layers:

For dukas, this is invisible—one inventory item, one catalog item, 1:1 mapping.

For enterprises, this enables repackaging, multiple SKUs from single inventory, and accurate stock depletion regardless of how items are sold.

Same data model. Different levels of usage.

The Technical Architecture

Here’s how we structured the system to support both paths.

Feature Flags via Tenant Settings

Components conditionally render based on mode. Simple mode hides complex analytics, procurement workflows, and multi-store features. Enterprise mode unlocks everything.

Per-Store POS Settings

Different stores (even within the same tenant) can have different configurations:

• Payment methods enabled
• Customer field visibility
• Discount limits
• Credit sale permissions

A chain can have strict settings at their flagship store (require customer, 20% max discount) and relaxed settings at their kiosk (walk-in only, no discounts).

Service Layer Handles Both Paths

The same underlying service can handle simple operations (Quick Add Stock with auto-approval) and complex operations (formal adjustments requiring manager approval). Same models, different entry points.

What We Learned

1. Talk to Both Extremes Early

We spent days in actual dukas watching owners work. We also interviewed operations managers at retail chains. The insights were dramatically different:

• Duka owner: “I just need to know what I sold today and what to reorder.”
• Ops manager: “I need to know which batch of milk is expiring tomorrow across 12 locations.”

Both are right. Both are paying customers.

2. Complexity is a Feature for Some Users

Enterprise users don’t see approval workflows as “complexity”—they see them as control. Removing them would make the product unusable for their compliance requirements.

The goal isn’t to eliminate complexity. It’s to gate it appropriately.

3. Migration Paths Matter

A duka that grows into a mini-mart shouldn’t have to switch products. We designed explicit graduation paths:

• Start with Quick Add Stock
• Later, enable Purchase Orders when you have regular suppliers
• Later, enable GRN when you need batch tracking
• Later, enable Stock Transfers when you open a second location

The data model supports all of this from day one. Features unlock progressively.

4. Defaults Are Your Biggest UX Decision

The choice to default to Simple Mode, hide the customer field, and enable M-Pesa out of the box—these decisions define who feels “at home” in your product.

We chose to make dukas feel at home. Enterprises can configure. This is an intentional product stance.

The Duka-Enterprise Spectrum

Here’s how features map across the spectrum:

The Universal Pattern

The duka dilemma isn’t unique to Kenya or retail. It’s the fundamental tension in B2B software:

• Notion serves solo users and enterprise teams
• Shopify serves bedroom entrepreneurs and billion-dollar brands
• QuickBooks serves freelancers and mid-size companies

The pattern that works:

1. Start simple — Nail the core workflow for your smallest user
2. Layer complexity — Add enterprise features as optional layers
3. Use smart defaults — Make the simple path the default path
4. Design for graduation — Let users grow without switching products
5. Respect both users — Neither is a “lesser” version of the other

Conclusion

The duka owner paying $10/month deserves the same quality of experience as the enterprise paying $500/month. They just need different amounts of that experience.

Build for the duka. Scale to the enterprise. Serve both without compromise.

Sokosuite is a POS and inventory management system built for Kenyan retailers. We serve everyone from single-owner dukas to multi-location retail chains.