Case study
Boutique publisher platform
Sahly is a sales and finance system for a boutique publisher. It began as a search for where AI could help, and found a weekly admin job that was also a recurring financial risk.
Where it started
This engagement did not begin with a brief. It began with sitting down with a boutique publisher to understand the business and the industry end to end, looking for where the work was inefficient and where AI could genuinely help rather than merely be applied.
What surfaced was not the problem anyone would have written on a list. It was sales report collation: a manual assembly job that ate hours every week and produced errors as a matter of course.
Why it stayed unsolved
Publishing is not short of software. It is short of software built for this.
What is available is generic by design: accounting packages, inventory tools and reporting suites that can be bent towards a publisher's shape but were not drawn to it. None of them know what a title is, how a royalty is calculated, or why those two facts are the same fact. So the bending is done by hand, in a spreadsheet, every period.
The obvious alternative, commissioning something custom, reads as far-fetched for a business this size, and not only on price. A bespoke build is a project you end up running: months of specification, a vendor to hand-hold, and a system whose only expert leaves when the invoice is paid. For a small team, that is a second job nobody wants.
So the spreadsheet stays, and gets rebuilt every period by whoever understands it.
Why it mattered more than it looked
A boutique publisher sells the same title through several retailers and several channels, each reporting differently, on its own schedule, in its own format. Assembling that into one picture by hand would be a tolerable chore, except for what sits downstream of it.
Author royalties are calculated from exactly those numbers. Royalties are a contractual obligation with a person's income attached, which means a collation error is not an inconvenience. It is either an underpayment to an author or an overpayment by the publisher, and both are discovered late if they are discovered at all.
A weekly admin task and a recurring financial risk turned out to be the same task.
What we built
A sales and finance system built around the publisher's actual unit of work, the title.
- Title-level sales tracking across every retailer and channel
- Author royalties calculated automatically from those sales, rather than reconstructed by hand
- Reporting the team can read without rebuilding a spreadsheet to get it
The design goal was that the royalty figure stops being something anyone assembles. It becomes something the system already knows, because it has been tracking the sales it derives from all along.
What changed
The weekly collation is gone as a manual task. The hours it consumed return to the team, and the reporting that used to be the output of that work is now available without anyone producing it.
The more valuable change is upstream of the money. Royalties are calculated from tracked sales rather than from a hand-built sheet, which removes the class of error that produces silent revenue leakage, in both directions. A publisher can be confident authors are paid what the contract says, and can show its working.
In their words
“Everything on the market was built for somebody else and bent to fit us, and none of it understood what a title or a royalty actually is. Having something custom built felt out of reach, and honestly like a project we would end up running ourselves. What we have instead was built around how this business really works, and the royalty numbers now come out of the sales rather than out of a spreadsheet somebody rebuilds every period.”