模塊 module
Software built from parts that already work.
Mokuo builds software for businesses that still run on paper, phone calls and memory. We build it out of modules we have already proven, so you are paying for the part that is yours - not to rebuild the parts that are not.
The tools exist. They just do not fit.
A one-person shop, a small studio, a family business. The software on offer is either built for a company fifty times the size, or it is a template that does nine tenths of the job and fights you on the tenth.
So the work stays where it has always been: a notebook beside the bench, a phone that rings at dinner, a price list somebody has to keep in their head. It works, right up until the day it does not.
Custom software solves that, and then presents a bill for building the same foundations everybody else already has.
Every business needs the same spine.
Scheduling. Inventory. Customers. Messages. Announcements. Taking payment. Knowing who somebody is. Underneath almost any business application it is the same handful of things - and most of the cost of custom software is building them again from nothing, as though nobody ever had.
Mokuo builds them once, as modules that own their own data and their own rules. A module asks the others questions rather than reaching inside them, so one can be replaced, or reused in the next product, without the rest noticing.
What is left to build is the part that is genuinely yours: the thing your business does that nobody else's does. That is where the name comes from.
RacketPilot assembled from eight of them
RacketPilot.
Badminton stringing, booked and tracked.
Racket stringing is a real trade with a real backlog: frames waiting on a bench, a string shelf that runs out halfway through a job, customers who text at midnight asking whether it is ready.
RacketPilot gives a stringer their queue, their shelf and their price list in one place, and gives a player somewhere to book a restring and watch it happen. It was built alongside a working stringer rather than for an imagined one - which is why it knows what a split tension is.
How it is built matters as much as what it does.
The reasoning is written down beside the code.
Not notes explaining what a line does - the argument for why it is that way, kept next to it. Most codebases lose that within a year of being handed over, and every decision then gets re-made by somebody guessing.
Security is a default, not a feature to be added later.
Sign-in happens on a dedicated accounts service. Access tokens never reach a browser, and a password is never typed into an app. These are decisions made at the start, because they are expensive to retrofit and quiet when missing.
AI is part of how the work is done.
It reviews, it catches what one developer working alone would miss, and it holds the standard on a tired Friday afternoon. A tool in the process rather than a claim on the label.
Tell us what your business is still doing by hand.
That sentence is the whole brief. If a notebook, a spreadsheet or a group chat is holding something together, there is usually a better answer - and often a smaller one than you would expect.