Start at the part that makes you different.
Accounts and logins. Teams, roles and who-can-see-what. Documents that route for approval. Forms. Many customer organisations on one system. Every business product needs all of it before it can do the thing it is actually for — and here it is already built, already tested, and free to run on your own servers.
All of it is available to an AI agent from the first day, with no integration project and no chatbot bolted on the side.
post_api_v1_documents
post_api_v1_documents_id_routes_from_template
get_api_v1_documents_id_trail
The months before month one.
Every business product spends its first stretch building the same foundation, and none of that work is what customers pay for. Here is the honest split.
Working on day one
- Sign-up, sign-in, password reset, two-factor
- Single sign-on with Google, Microsoft or Okta
- Teams, roles, and who-can-see-what
- Many customer organisations, kept apart
- Documents, approval routing, audit trail
- Forms, in Arabic and English
- An AI agent that can already use all of it
Still yours to build
- Whatever your product actually does
- Accounting and a general ledger
- Inventory, orders and purchasing
- Payroll
- A sales pipeline
- Deciding what to charge, and who for
Whity is a foundation, not a finished business system. If you need accounting or inventory out of the box, you want an ERP, and you should buy one.
The parts every product rebuilds.
Done once, tested properly, and the same underneath whatever you build on top.
Logins that already work
Sign-up, sign-in, password reset, two-factor, and single sign-on with Google, Microsoft Entra, Okta or anything standard. Nobody on your team has to write a password reset flow again.
Many customers, one system
Serve every customer organisation from a single deployment with their data kept strictly apart. It is what every B2B product eventually needs, it is unforgiving to get wrong, and it is already here.
Who can see what
Your customer's real org chart, with roles that flow down it. A regional manager sees their region without anyone assigning permissions person by person, department by department.
Documents that get signed
Design them once, send them for approval, see where each one has got to, and keep a record of who did what and when. Multi-page, reusable sections, QR verification, Arabic included.
Forms people fill in
Built from a definition rather than hand-coded screen by screen, bilingual by default, and able to start the same approval routes documents do.
Your part stays yours
Your product's own features drop in as plugins without touching the foundation. They can stay closed-source and be sold commercially — that is written into the licence, not a favour.
Your agents can already run it.
Most products add AI by bolting a chat box onto what already exists, then spend months teaching it what the software can do — and re-teaching it every time the software changes.
Whity works the other way round. The list of things an agent can do is generated from the software itself, so it is complete the day you install it and cannot fall out of date. There is no integration to build and nothing to keep in sync.
And an agent is held to the same rules as a person. It acts on behalf of someone and gets exactly their permissions — never more. An agent working for a technician cannot read what a technician cannot read.
What this changes
- No integration sprint. What the agent can do comes from the product itself, not from a connector somebody has to write first.
- Nothing to maintain. Ship a new feature and agents can use it immediately, because nobody listed the old ones by hand.
- Safe by construction. Permissions are checked in the same place for agents and people, so there is no second set of rules to get wrong.
- Your customers' agents too. Not only yours — anyone you give access to can point their own assistant at it.
Sell into Arabic markets without a rewrite.
Most software treats Arabic as a translation added at the end, which is why so much of it looks wrong to the people using it. In Whity a name carries its Arabic and English versions together in the data itself, and screens genuinely mirror for right-to-left rather than flipping and hoping.
A contract can put an Arabic clause beside its English version on the same page. If your market is the Gulf, the Levant or North Africa, that is the difference between a product that looks local and one that looks translated. Whity is built in Jordan, for organisations that work in both languages every day.
No one can take it away, or put the price up.
It runs on your infrastructure
Your cloud account, a rented server, or a machine in your own building. Your customers' data stays where you put it, which is often the whole reason a deal closes.
There is no bill to grow into
No per-seat pricing and no usage tier that changes the maths when you succeed. The core is free software and stays that way.
Your code can stay closed
The core is AGPL-3.0, so improvements to it are shared. The plugin SDK is MIT, so what you build on top is yours to license and sell however you like.
Straight answers.
What is Whity, in one sentence?
Whity is the foundation a business product sits on — accounts and logins, teams and permissions, an org structure, documents that route for approval, and forms — already built, already tested, and free to run on your own servers. Every one of those actions is also something an AI agent can do, without an integration project.
What do I still have to build?
Whatever your product actually does. Whity gives you the part that is the same in every business product; the part that makes yours worth paying for is yours to write, and it drops in as a plugin. Whity also deliberately has no accounting, inventory, payroll or sales pipeline — it is not an ERP and does not pretend to be one.
Do I need engineers to run this?
Yes. Whity is not a no-code tool. You need someone who can run a server and deploy software — one developer is enough to get it running, and the install guide is written for that person. What it saves is not the need for a team, but the months that team would spend rebuilding logins, permissions and approvals before writing a line of your actual product.
Can I build a business on it? What is the licence?
Yes. Whity Core is AGPL-3.0-only, so you can run it, modify it, host it and sell services around it. The plugin SDK is MIT, which matters commercially: a plugin built against it can stay closed-source and be sold under any terms you choose. Your product's own code does not have to be given away.
How do AI agents actually use it?
The list of things an agent can do is generated from the software itself rather than written by hand, so it is complete on day one and cannot drift out of date as the product changes. An agent acts on behalf of a person and is held to exactly that person's permissions — it cannot see or do anything they could not.
Does it work in Arabic?
Yes, as a first-class concern rather than a translation bolted on afterwards. Names and labels carry their Arabic and English versions together in the data itself, screens mirror properly for right-to-left rather than just flipping, and documents can put an Arabic clause beside its English version on the same page. Whity is built in Jordan.
What does it run on? (for your CTO)
PHP 8.4 on FrankenPHP persistent workers, PostgreSQL 15 with logical tenant isolation, and a Next.js web client. It runs under Docker and self-hosts anywhere — your own cloud account, a rented server, or on-premises. The platform page has the architecture in full.
How it actually works.
Longer pieces, written for the person on your team who will ask the hard questions.
Every API route is already an agent tool
Most products bolt a chat box onto an existing API and call it agent support. Whity derives its MCP tool catalogue from the same schema the router already generates — so the tools cannot drift, and an agent gets exactly the permissions its token carries.
Read →Arabic is not a translation pass
Bolting a second language onto a finished product produces a product that works in one language and apologises in another. Here is what treating Arabic as a first-class case actually cost us: a generated English catalogue, a sync that cannot overwrite a human, and layouts that mirror.
Read →Tenant isolation and the plugin boundary
How Whity enforces multi-tenancy three separate times, why plugins never touch core source, and why that boundary is also what makes closed-source plugins possible under the licence.
Read →One line. Then it knows the rules.
Paste it into Claude Code, Cursor, or whatever you build with. Your agent fetches the setup instructions, works out whether it is looking at the core platform, a plugin project or an empty directory, and writes the project's conventions into your agent instructions file so they survive the session.
You can read exactly what it will execute first — the instructions are a plain markdown file, not a script.
Copies one line to your clipboard
Fetch and execute the appropriate instructions to set me up for Whity from https://whity.dev/agent-setup/prompt.mdLet it drive a real instance.
The line above is enough for an agent writing code. To let one operate a running Whity — create a tenant, assign a role, file a form — connect it to that instance's MCP endpoint. It gets exactly the permissions its token carries, enforced by the same component that guards the HTTP API.
Whity is self-hosted, so the endpoint lives on your own instance; there is no shared server to point at. Issue a token with a human access token, then configure your client.
curl -s -X POST https://your-whity-host/api/mcp/tokens \
-H "Authorization: Bearer <your-access-token>" \
-H "Content-Type: application/json" \
-d '{"name": "my-agent", "scope": ["tools:call"]}'{
"mcpServers": {
"whity": {
"url": "https://your-whity-host/mcp",
"headers": {
"Authorization": "Bearer <mcp-token>"
}
}
}
}See it running before you commit to anything.
One command brings the whole thing up on your own machine. Nothing to sign, no sales call, no trial clock.