The small-shop edition is the same product with payroll, gift cards and quotations taken out on purpose
A deliberately reduced point of sale for shops with one register and no HR department. It's half the size of the full product: buy, sell, return, cash and staff kept, and everything else removed outright.
The brief, in specifics
E-commerce & Retail
12 weeks
Fixed price
Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.
What was there, and what replaced it
Their large product was losing small deals, and price wasn't the reason. Owners opened it, saw departments, payroll, gift cards, coupons, quotations and product variants, and concluded it wasn't for them. Hiding those behind permissions didn't help: the menus were still there, and configuring a system to be smaller isn't a job a shopkeeper wants.
First open is where the small deals were lost, and no amount of configurability reaches it. A permission-hidden module still leaves its vocabulary in the interface (a stray label, an unreachable setting, a report column with nothing in it), and each of those is a question that reaches support from a customer who was already unsure the product was for them.
A separate edition where the cut is real. Buy, sell, both directions of return, cash register, expenses, suppliers, customers and staff. No departments, no payroll, no gift cards, no coupons, no quotations, no variants. The reduction is the feature, and it's visible on the first screen.
What we inherited
The flagship point of sale was being sold to shops that used a fifth of it. We built the small-shop edition: the same ledger discipline, seventeen models instead of forty-three, and a settings screen that fits on one page.
A software vendor whose flagship point of sale was losing small deals at a rate nobody could explain from pricing. The engagement started from their own lost-deal notes, which said the same thing repeatedly in different words: the product was for somebody bigger. Twelve weeks were scoped to build a separate edition, not another configuration layer.
Full-Stack Engineering
What we kept, and what we cut
- 01
Cut modules out of the edition instead of hiding them behind permissions
Removed modules are absent from the build, so no stray label, setting or empty report column survives the cut.
- 02
Kept both directions of return, because returns are where small shops most need the discipline
Keeping returns was decided from usage data across existing small customers, and the guess everyone had made beforehand would have cut them.
- 03
Kept the cash register, since a one-register shop reconciles more often, not less
The cash register stayed, since a one-register shop closes daily against a drawer and has no accounts department to find a discrepancy a week later.
- 04
Reduced staff handling to roles and permissions without an HR module attached
The line was drawn by asking which modules an existing small customer had opened more than twice, and payroll had been opened by none of them.
- 05
Held the same ledger model as the full product, so the data isn't a dead end if a shop grows
The schema matches the full product exactly, so outgrowing the edition moves data and nobody retypes a year of history.
The cut is real
Removed modules are gone from the build, so the menus a shopkeeper sees are the ones they use.
The removed modules are genuinely absent, not hidden behind permissions, so a shopkeeper's menu contains only what they use. Hiding by permission leaves the complexity in the codebase and the vocabulary in the interface (a stray label, an unreachable setting, a report with an empty column), and every one of those is a question that reaches support.
- Removed modules absent from the build, not permission-hidden
- No stray labels, settings or empty report columns
- Complexity gone from the interface and the codebase
Every setting the edition has, on one page: shop details, three tax rates, three payment methods, users and backup, under a notice naming payroll, gift cards and quotations as absent, not locked.
Returns in both directions on one screen: two lines ticked off an invoice for a £21.45 card refund, three damaged supplier lines worth £35.50 of credit, and between them the stock each movement produces.
Returns kept in full
Both directions survive the cut, because returns are where a small shop's numbers most often go wrong.
Both directions of return survived the cut, because returns are where a small shop's numbers go wrong most often, and a single-register business has nobody to catch it later. They work exactly as in the full product, reversing the original movement instead of compensating for it, so the arithmetic is right by construction, with no one needing to check it.
- Purchase and sale returns both kept in full
- Identical mechanism to the full product
- Right by construction, not by someone checking
Cash register kept
A one-register shop closes daily, so reconciliation matters more at this size, not less.
A one-register shop closes daily and reconciles against a drawer, which makes the cash register more important at this size, not less: there's no accounts department to find a discrepancy a week later. Opening float, movements, expenses paid from the register and the closing count are all part of one closing record.
- Daily close with float, movements and counted cash in one record
- More important at one register, not less
- Register-paid expenses included in the close
The one-register close: a denomination-by-denomination cash count landing £1.50 short of the expected drawer, takings split by payment method and by category, and the Z-report printing beside them.
Staff as roles and nothing more: four people, a role matrix where a cashier may void a line mid-sale but not a completed sale, and attendance, payroll and schedules listed as removed from the build.
Roles without HR
Who can void a sale is a real question; attendance tracking for three people isn't.
Roles are kept and HR isn't. Who can void a sale, apply a discount or open the register is a real question in a three-person shop; attendance tracking and payroll for three people is administration in search of a problem. The line between the two was drawn by asking which module a shopkeeper would actually open twice.
- Voids, discounts and register access are real role questions
- Attendance and payroll cut at three staff
- Line drawn by what gets opened twice
Shared ledger model
The buying half of the ledger: six purchase orders totaling £4,286.40 across received, part-received and draft, the month's five running expenses, and a delivery being booked in against an open order, posting to the ledger model the full product shares.
The schema matches the full product, so outgrowing the edition means moving data, never retyping it.
The schema matches the full product exactly, so outgrowing the edition is a data migration, with no year of history to retype. That was the constraint that shaped every cut: nothing could be removed in a way that would turn the upgrade path into a fresh start.
- Identical schema to the full product
- Outgrowing the edition moves data; nobody retypes it
- No cut was allowed to break the upgrade path
Phase by phase
Phase 1: Deciding The Cut
What A One-Till Shop Uses
Went through the full product's modules against real small-shop usage. Departments, payroll, gift cards, coupons, quotations and variants were used by almost nobody at that size and cost every user attention.
- Module Audit
- Cut List
- Edition Scope
Phase 2: The Core
Buy, Sell, Return
Built purchase, sale and both return directions on the same ledger discipline as the full product: the part that has to be right however small the shop is.
- Purchases
- Sales
- Returns Both Ways
Phase 3: Cash And Expenses
The Daily Close
Built the cash register and expense handling, because a shop with one register closes it every day, and that's the moment the numbers are either right or not.
- Cash Register
- Expenses
- Daily Close
Phase 4: People, Lightly
Roles Without HR
Built staff as roles and permissions and stopped there. A shop with three people needs to know who can void a sale; it doesn't need attendance tracking.
- Staff
- Roles
- Permissions
Phase 5: The Upgrade Path
Not A Dead End
Kept the ledger model identical to the full product, so a shop that outgrows the edition moves its data instead of retyping it. That's what makes the cut safe to make.
- Shared Schema
- Data Portability
- Upgrade Route
The edition manifest: forty-three models in the full product, seventeen kept across ten modules, twenty-six cut across eight, none hidden behind a permission, and the ledger model marked as shared.
After the rebuild
43
Models, full product
17
Models, small edition
0
Modules hidden rather than cut
Shared
Ledger model
Models in each product is a count of domain models. Modules hidden rather than cut is zero: the removed ones are absent from the build. Shared ledger model describes the schema relationship: the small edition's data fits the full product's shape exactly.
Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.
What the rebuild taught us
A product that can be configured smaller is still a big product on first open, and first open is where small deals are lost.
Configurability answers a question small buyers never ask, because they've already decided by the time they'd reach the settings.
Cut modules out instead of hiding them. A menu behind a permission is still a menu somebody has to dismiss.
Hiding isn't cutting: a menu behind a permission is still a menu, and its vocabulary still appears in reports, settings and support conversations.
Decide the cut from usage data, never from a guess about what small customers want.
The cut was decided from usage, not intuition, which is why returns and the register survived and payroll didn't. The guess would have gone the other way.
Keep the schema shared, and a reduced edition stops being a dead end for the customers who grow.
A shared schema is what stops the reduced edition being a dead end, and it costs nothing at design time and everything to retrofit.
How we worked alongside the team
- 01
The cut list came from the vendor's own usage telemetry, not from a workshop. That mattered: two modules everyone assumed small shops needed were barely touched, and one everyone expected to cut (the cash register) turned out to be used more heavily at that size, not less.
Twelve weeks, fixed, with the cut decided from usage data across the existing small-shop customer base instead of from opinions about what small shops want. Every module was assessed on whether a shopkeeper would open it twice, and the schema was constrained throughout so that outgrowing the edition would be a data migration, never a fresh start.
Forty-three models, then seventeen
A menu behind a permission is still a menu. So the modules left the build.
The full product laid out by module, then the small-shop edition taking eight of them out, then the difference between hiding a module and cutting it, with the ledger model both editions share. Switch tabs, or use the arrow keys once one is focused.
The flagship point of sale: departments, payroll, gift cards, coupons, quotations and product variants beside the buying, selling and cash a small shop actually uses. Owners opened it, saw all of it, and concluded it was for somebody bigger.
- Ledger1Movement
- Catalogue3Product · Category · TaxRate
- Variants4VariantGroup · VariantOption · ProductVariant · VariantStock
- Selling3Sale · SaleLine · PaymentMethod
- Coupons3Coupon · Promotion · Redemption
- Gift cards2GiftCard · GiftCardBalance
- Quotations3Quotation · QuotationLine · QuotationRevision
- Returns2ReturnNote · ReturnLine
- Buying2PurchaseOrder · PurchaseLine
- Suppliers1Supplier
- Customers1Customer
- Cash register1CashSession
- Expenses1Expense
- Departments3Department · DepartmentTransfer · DepartmentTarget
- Staff2User · Role
- Attendance3ClockEvent · Timesheet · LeaveRequest
- Rotas2Rota · Shift
- Payroll6Employee · Contract · PayrollRun · Payslip · PayComponent · Deduction
- Departments3
- Payroll6
- Attendance3
- Rotas2
- Gift cards2
- Coupons3
- Quotations3
- Variants4
Why the cut was safe to make: it was decided from which modules existing small customers opened more than twice, and no cut was allowed to break the upgrade path. Step timing is illustrative.
From a scan at the register to a close that adds up
The edition is smaller at the edges and identical in the middle. What was cut never reaches the build; what was kept runs on the same ledger discipline as the full product, because that part has to be right however small the shop.
- 01 · SourceRegister and back office (Blade, jQuery)A sale, a purchase or a return either way. The menus hold only modules a shopkeeper uses; removed ones are gone from the build.
- 02 · GateLaravel controllers and rolesWho can void a sale, apply a discount or open the register is decided by role, with no HR module attached.
- 03 · EngineLedger disciplineA return reverses the original movement instead of compensating for it, so the arithmetic is right by construction.
- 04 · StateMySQL · 17 of 43 modelsThe ledger schema matches the full product exactly, so outgrowing the edition moves data instead of retyping it.
- 05 · CloseDaily close and Z-reportOpening float, movements, expenses paid from the register and the closing count sit in one closing record.
What a smaller product can't lose
Money, permissions & a cut that stays cut
The money-critical parts were kept whole
Both directions of return work exactly as in the full product, reversing the original movement. The cash register stayed, with float, movements, register-paid expenses and the count in one closing record, and the ledger model is the full product's own.
Staff get roles, not the run of the register
Voids, discounts and opening the register are role questions, answered by roles and permissions. What was cut is attendance tracking and payroll; control over who can change a sale stays.
Nothing cut can resurface
Removed modules are absent from the build, so no stray label, unreachable setting or empty report column survives for a setting or a role change to bring back.
Is your product too big for your smallest customers? Scope your build in 3 minutes.
Scope your buildNearby engagements
Data & AnalyticsA checkout that stopped losing sales to a 6-second load
Profiling found the real bottleneck behind a slow checkout (an N+1 query and an oversized bundle) and tuned both, with before-and-after metrics locked in as a baseline against future regressions.
E-commerce & Retail · 5 weeks
Web PlatformsA reader people finish, and a library that remembers where they stopped
A reading platform for a comics catalog: a browse surface people can actually navigate, a reader that gets out of the way, and a history that puts everyone back on the page they left.
E-commerce & Retail · 18 weeks
Web PlatformsOne number, a whole handset, and a database that keeps up with 125 brands
A metered IMEI lookup service that turns fifteen digits into a device, its specifications and its status. It's sold three ways to three audiences and backed by a device database that maintains itself.
Consumer Electronics · 22 weeks
Let's talk
Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.
