About · Wages.software
Who stands behind this, and what we will not tell you because we cannot.
Wages.software is operated by Stanley Studios. It is a for-profit software product. It is not a school, not a district, and not a nonprofit, and nothing on this site is a charitable gift of any kind — this is software a school buys, and we are precise about that difference because in this sector it matters.
It is early access: the calculation engines are written and covered by twelve gate suites that run green, and the service around them is not built. That sentence is on the first screen of the home page rather than in a renewal call, which is roughly the whole editorial policy of this site in one example.
The one idea
The engine, not the service.
The national payroll providers sell a result. You send the hours and a number comes back, and for most schools that is a good trade — it is the reason most of them buy payroll software at all. But the arithmetic in the middle is not published anywhere you can read it, so when a number looks wrong there is nothing to check it against.
This product is the arithmetic in the middle. Gross-to-net in exact integer cents. A separate taxable basis for every authority. Federal withholding worked the way the IRS worksheet is actually written. FICA at rates held as exact rationals so 1.45 percent is never rounded. A direct-deposit batch proven against the structural rules a receiving bank checks. A W-2 to W-3 to 941 reconcile that blocks the year rather than balancing it for you. Each step is its own endpoint, and all of it is legible.
And it disburses nothing, files nothing, and ships no statutory tax tables. Those three are not a roadmap. They are the shape of the product, and they are the first three rows of our own comparison table — the rows a full-service provider wins outright.
Why build the shape nobody asks for. Payroll is one of the few categories where being confidently wrong is worse than being useless. A scheduling tool that guesses badly wastes an afternoon. A payroll engine that guesses a withholding rate produces a number that looks exactly like a correct number, on every paycheck, until a notice arrives from a taxing authority eleven months later. So this product was built around a refusal before it was built around a feature, and the refusals are the part we lead with.
How to check us without trusting us
Four things on this site you can verify in one click.
This is not a claim about our character. It is a claim about the pages you are already looking at, and each one is a link away.
Every capability is named by its module
Each engine carries the file that owns the decision and the functions a handler calls. You can take a name off the page and go looking for it rather than take the sentence on trust.
What does not work is listed by name
Eleven modules are written, tested and called by nothing. They are named, with what each does and why it is not reachable — and the five gate suites that test one are paired to it.
The comparison concedes before it argues
The full-service model wins the first three rows outright: it runs payroll, it files, it maintains the tables. Where we would have to assert what another company’s code does internally, the table says we have not established it, because we cannot read their source.
One measurement, and it is a count
Twelve gate suites, sixty-two tests, run green before the pages were written. That is the only number quoted anywhere on this site, and it is a count of files and tests rather than a percentage of anything.
How this site is written
Three rules that decide what goes on a page.
Marketing copy for a technical product fails in a specific way: every individual sentence is nearly true, and the page as a whole says something that is not. These three rules exist to catch that, and each of them has visibly changed a page on this site.
A calculated value is never described as a stored one. This is the subtle one and it is the one we got wrong. An earlier version of the home page described the self-service lane’s direct-deposit election and its hash-chained change events as persisted state — it said the election was recorded, the account was stored masked, the event was appended to a chain. Every individual word was nearly right: the engine really does validate, mask and hash. Then it returns the result and keeps nothing. Records, stored and appended are all persistence verbs and every one of them was false. The replacement vocabulary is deliberate and it is used throughout: validates, returns, computes, masks.
We never assert what another company’s code does. An earlier version of the comparison table said a competitor rounds sub-cent fractions internally and models an approval as a status flag on a run. We cannot read another company’s source, so both were unfalsifiable guesses pointing in the direction that flattered us — and one of them contradicted the table’s own caption. They are gone. What replaces them is an asymmetry we are comfortable with: our behaviour stated precisely, and “not established” where theirs would have to be guessed. Vendor names appear exactly once on this site, in a single factual footnote under that table.
A capability claim gets re-tensed; a promise never gets deleted. When something turns out not to work the way a page said, the sentence changes tense — built becomes built and not switched on. But a safety statement is not edited out to make a page read better. Removing a capability claim is honesty; removing a promise is the opposite, and the two diffs look identical, which is exactly why the rule has to be written down.
What this page cannot tell you
Four things an about page usually carries, and why none of them is here.
There is no founding story. Some products come out of an operation the people building them were already running. This one did not, and it would be easy to write a paragraph implying otherwise. We do not run payroll for anyone — that is the first thing this site says about itself — so there is no operating history to tell you about, and a story assembled to fill this space would be the only dishonest thing on the site.
There is no team page. No headcount, no photographs, no titles. Stanley Studios stands behind the product and answers the address at the bottom of every page; beyond that there is nothing here we could publish that would tell you something true and useful.
There are no customers named, and no adoption figures. Not a count of schools, not a logo wall, not a testimonial, not a percentage. This is early access. Any number in that shape would be invented, and an invented number on a page about payroll arithmetic would undo the argument the rest of the site is making.
And there is no price. There is no pricing page on this site and no checkout anywhere on it, because money is switched off end to end: there is no charge rail and no disbursement rail. A pricing page for a product you cannot buy implies that you can.
Naming these rather than leaving them out is deliberate. An unexplained gap reads as an omission; a named one is an answer. If any of the four changes, it will change on this page with the date attached.
Where this sits in a school
Next to an ERP, not instead of one.
In schools specifically, the incumbent is usually a district ERP that owns the whole back office and treats payroll as one module inside it. We are not that shape and are not trying to become it: no suite, no system of record, and no ambition to be the place your general ledger lives.
Where a calculation surface is useful next to an ERP is narrow and real. You can read the calculation, call one step of it, and reconcile a year against it independently. If a district ERP hands your business office a number nobody can explain, this is what you point at it. We will not tell you how any particular ERP computes internally, because we have not read it and cannot.
Two seams are deliberately unwired, and we would rather name them here than let you find them in an evaluation. There is no electronic signature: the endpoint returns a clear service-unavailable saying e-sign is not provisioned. We have not integrated any third-party signing provider and have not written a signature of our own, and recording a signature we did not collect would be a far worse failure than refusing one. And there is no benefits carrier connection: an election is validated against the enrollment window and the employment lifecycle and comes back with its carrier status held at pending, and the carrier-submission endpoint refuses the same way. Nothing is sent to any carrier.
Money out to staff is also kept apart from money in from families on purpose. The family-billing side of a school’s money is tuition.software, and the requisition rail is procurement.center and procurement.management. Each is its own product rather than a module of a suite, which is the same argument as this page, applied one level up.
What we will and will not do with data
Staff data, walled at the row. Not children’s data.
Payroll and HR are staff-coupled surfaces. The records carry opaque staff and employee references and no student identity, and they sit deliberately outside the student census wall rather than inside it. No minor’s data enters this product at any point. That is a design decision rather than a happy accident: a payroll engine has no business holding a roster.
To be exact rather than flattering, and this is the version we would rather you quote: this is not a claim that we hold no data. An employee record is data, and compensation data is among the most sensitive a school keeps. The honest claim is narrower — it is staff data, referenced opaquely, walled at the row and at the tenant, masked where it is dangerous, and it is not children’s data.
Bank account numbers are returned masked to the last four digits and are never echoed in full. On the self-service lane they are not stored at all, because those endpoints persist nothing. The full posture is on privacy and data.
Where to go next
The rest of this site.
Every page here is its own argument rather than a restatement of the home page. If you would rather ask a person, the address below reaches one.