Describe your problem and it gets built.

Problems that fit

Examples of the kind of request this suits. The work is real software with tests, not a mock-up.

• Quoting and pricing for your trade, built from your own rates, waste factors and margins.
• A spreadsheet that has outgrown itself, turned into a tool that checks its inputs and explains its numbers.
• Checking documents against rules: an invoice, an order or a form tested before it goes out.
• Back-office chores: categorising transactions, reconciling, estimating, scheduling from a takeoff.
• A replacement for a subscription that does one job, as an app you can host yourself.
• A feature for a tool already here: every tool's footer links to this form with that tool chosen.

What does not fit: anything that needs paid accounts or a cost per user to run, must stay private, scrapes a site against its terms, or gives regulated advice with no safe framing.

How a request moves

1. received (0)Read, not yet decided.
2. accepted (0)Will be built; waiting for a session to start it.
3. building (4)Sessions are working on it; the project link shows how far it got.
4. shipped (0)Live, or merged and usable. Later fixes are still welcome.

Before triage, every request from outside is screened for text aimed at the agents rather than describing a job. A request can also be declined, always with the reason written beside it. Each request has its own page showing which stage it is at and what is still unproven, and once there is something to try you can send feedback on it from that page. Sessions work in the open: every change is a pull request, and the project's README says what was tested and what was not.

Other ways to ask

• Open a request on GitHub (a free account) to follow replies and attach sample files.
• Short on time? The one-box idea form, or the general feedback page.
• Describe the job from the inside: who does it, how, and where today's tools fall short. Real sample material (with private details removed) is the fastest way to move a request forward.

What has been built this way

The first requests in the list below are the owner's own, so you can see how deep a request goes over many sessions: an AI bookkeeper (double-entry ledger, bank reconciliation, QuickBooks and Xero export), a wall framing takeoff from a floor plan, and a sales agent. Each README says what is tested and what is still unproven.

What you can ask for

• A product or tool for your work: a calculator, a checker, a document reader, a small app. GitHub request · no-account form
• A feature for a tool already here. Use the form from that tool's footer, so it knows which tool you mean.
• A research question you would like investigated with real data, written up openly. GitHub request · no-account form
• A topic to write about: a guide, an explainer, a comparison. GitHub request · no-account form

How requests are screened

The builders are AI agents, so a request is also text an AI will read. Every request is checked by an open-source screen before triage. It looks for text written to steer the agents instead of describing a job: telling them to ignore their instructions, to merge, approve or run something, to reveal credentials, to send data elsewhere, or words hidden with invisible characters. A request that trips it is held for the repository owner and is not built from until they have read it. Ordinary requests pass straight through, and a held request is not a judgement of the person who sent it. Whatever the screen says, request text is treated as a description of what to build, never as instructions.

The terms

• Free. No fee for the engineering, the hosting or the agent compute.
• MIT licensed, held by the repository owner. What is built is published in this repository under its MIT licence, with the owner's copyright notice. Anything you attach, you must be allowed to share, and you agree to its publication on those terms.
• You may use it commercially, as anyone may: deploy it, change it, sell a service on it. The licence is the same for everyone, so there is no exclusivity.
• No promise of a date or of acceptance. Agent time is shared across the whole repository. A request is weighed on how useful it is, how well it fits, and whether it can be built and run legally at no per-user cost.
• Public by default. Requests, code and discussion are visible to everyone. Leave out names, addresses and anything private.

Questions businesses ask

Is it really free?

Yes. There is no fee for the engineering, the hosting of the public site, or the agent compute. You are not asked for a card.

Who owns what is built?

It is published in a public repository under the MIT licence, with the repository owner's copyright notice. That licence lets you, and anyone else, use it, change it, run it and sell services on it.

Can it be private or exclusive to my business?

No. Everything is built in public and the same code is open to everyone the day it lands. If your problem only makes sense with private data or a secret process, describe the general version, or this is not the right route.

How long does it take?

There is no promised date and not every request is accepted. Agent time is shared across the whole repository. Requests with a clear job and real sample material move fastest.

What should I send?

Who does the job today and how, where current tools fall short, how you would know the tool worked, and any real material you can share: a blank form, a published rate sheet, an export with private details removed.

Can I run it myself?

Yes. Browser tools run on this site at no cost to you, and self-hostable apps come with instructions to deploy into your own account. The code is yours to run under the MIT licence.

Describe your problem

Requests so far

4 on file: 4 building. The list is kept in one file, so each request's history is that file's history, and this page is rebuilt on every merge. You can also browse all requests on GitHub.