The price that pays the owner's hour, worked out without an account

The baker who works through the night on orders and the 3D-printing maker with a full queue reach the end of the month with the same problem: they know exactly how much they sold and have no idea how much was left. The price was set by looking at a competitor's, household money lives in the same account as the business, and the answer to "was it worth it?" is a feeling, not a number.

The constraint we inherited from that picture is about data entry, not arithmetic. Asking "how much fixed cost fits into each unit?" of someone who has never done an allocation returns a guess that contaminates everything downstream, and a system fed on guesses produces a beautiful report with a wrong decision inside it. That is why the product's interface principle is a prohibition rather than a good intention: never ask the owner for information they probably cannot answer.

What Lucrei asks for is the month's fixed costs and the month's units sold, two things any owner answers from memory, and it derives the allocation by dividing one by the other. The same goes for production waste, which arrives pre-filled with the average for the manufacturing type (8% for 3D filament, 15% for resin, 3% for laser cutting) and stays editable for whoever knows their own workbench better than the market average.

The constraint came before the solution: asking for revenue from someone who does not trust the product yet is asking too early, and a calculator that only reveals the result after sign-up is lead capture dressed up as a tool. We decided the opposite: visitors see their own number first and decide afterwards whether they want an account.

The calculator that opens Lucrei's home page is a client component with no network call at all: no fetch, no server state, nothing stored. There are 8 fields on screen, material per unit, production time, what your hour is worth, waste, monthly fixed costs, monthly units, the price you charge today and the sales channel fee: plus 4 under "advanced", for energy and equipment depreciation, which only enter the arithmetic if they are filled in.

Business goals are four buttons instead of a percentage field (Survival at 10%, Growth at 20%, Expansion at 30% and Premium at 40% net margin) because someone selling handmade goods understands an objective better than an abstraction. The result comes back with the cost per unit, the profit per hour worked and a four-state verdict: below break-even, below target, on target or above the suggested price.

One detail that only shows up when you test with real people: the fields do not use the HTML numeric type. The browser treats "39,90" as an invalid value and returns an empty string, so the field wipes itself while the person is typing. We switched to a text field with a decimal keypad and the same Portuguese number parser the product's spreadsheet importer uses, which already understands both "1.234,56" and "1234.56".

The constraint here is trust: in a product that states how much you profited, the dashboard and the pricing screen only have to diverge once for the whole number to become suspect. It is a cheap failure to introduce: someone reimplements a formula on a new screen because it was faster than importing the existing one, and an expensive one to find, because the person who finds it is the user.

Every business indicator comes from a single metrics hub, and the calculation logic lives in pure modules, with no database and no input or output, each with its test file beside it. Data access sits in a thin wrapper on top. An architecture rule runs in CI and fails the delivery when someone redoes the arithmetic on the side, which turns the single source of truth into a mechanism rather than a verbal agreement.

That discipline is what lets the public calculator be honest: it imports exactly the functions that run inside the product, effective unit cost, labour cost, energy, depreciation per unit, margin by goal and profit per hour. If the formula changes inside, the page changes with it, because there is no second copy for anyone to forget to update. Today 1,642 automated tests across 130 files guard that contract.

Row-level multi-tenancy is the cheapest architecture to operate and the easiest to breach: all it takes is one query that trusts the identifier that came from the screen. The constraint we took on was removing that decision from the hands of whoever writes the query, because human attention does not scale across every screen of a product that only grows.

Every database query is scoped by the company identifier derived from the cryptographically validated session, never from what the user typed or what came in the URL. When the subscription lapses, the system switches to read-only: nothing is deleted and nothing is written, but everything stays readable, a customer leaving must never look like data loss.

The content security policy is issued per request with its own nonce rather than as a static header: in production the browser only executes the script that that specific page load signed. And the trail of login attempts lives in a table separate from the administrative audit log, with the email stored only as a hash: a burst of attempts does not drown the trail the operator needs to read, and a leaked log hands over nobody's address.

This product's number one trap has a name: the missing column. The database is SQLite hosted on Turso, reached by Prisma through the libsql adapter, and Prisma never does a generic select: it enumerates the schema's columns on every query. If the code ships before the migration, the first query in the authentication flow asks for a column that does not exist yet and login goes down for everyone at once.

The rule we adopted is that every migration must be additive and login-safe: add a nullable column, create a table, never drop, rename or impose a required field without a default. There are 56 migrations in the repository under that discipline, and a CI test fails the delivery when a new migration contains a drop, a rename, a column alteration or a required field with no default.

The production applier records each migration already executed in a control table with a checksum, so running it twice does nothing: idempotency is a property of the runner, not the operator's luck. And a rename of plan identifiers, which would be a one-way door, was deliberately kept out of the migrations folder: applying it would turn any code rollback into a silent plan downgrade, and the cost of holding it back is zero because an alias in the code already delivers the new vocabulary on screen.

Lucrei is whitelabel by birth: colours, logo and name change by configuration, and the same codebase becomes another operator's product with their own face on it. That forces the system to serve two customers at once: the owner who records the day's sale, and the operator who resells the platform and needs a proprietor's panel, with recurring revenue, a customer funnel and an audit trail of everything that happens.

For the owner, the opening screen summarises instead of dumping: 7 business health factors are condensed into 5 clickable pillars (Finance, Sales, Inventory, Production and Growth) which become a score from 0 to 100 and a sentence naming the weakest pillar. The micro-charts are hand-written SVG rather than a charting library, a decision that keeps that page around 158 kB against roughly 269 kB on the screens that load Recharts.

The growth plan takes the capital already invested and returns the target for the day, with a term control that slides from 3 to 36 months and recalculates in the browser while the person drags it. And the tax centre monitors the annual ceiling for MEI, Brazil's sole-trader regime, currently R$ 81,000, with an obligations traffic light and a calendar of dates, because blowing past the ceiling unnoticed is not an accounting fright, it is the loss of the regime itself.