OneProposal

OneProposal takes the context of a freelance project, the job and your background, and drafts the proposal you would have written by hand. The point is to stop rewriting the same structure for every new client and spend the saved time on the parts that actually win the work.

It is still being built, not market-ready yet. It is also the project that pushed me to build the agentic system the rest of this site keeps talking about, because the only way to make it reliable was to build the wrapper around the model, not just the model’s output.

What it actually is

Two pieces. A front end where you sign in, pay, and read the result, and a separate engine service behind it that does the real work. The engine does not just call a model and hand back whatever it says. It wraps the model in a research step that grounds the proposal in real signals, then runs the draft through a set of inline checks before anything reaches you: the line counts, the banned phrases, the price matching the brief, the sign-off present. The wrapper is the product. The model is one part inside it.

The hard parts

The one that taught me the most was a payment race. A tester pressed pay, the screen started generating, then fell back to the previous page, and a second click showed the finished proposal. No error, just a mismatch between when the payment landed and when the result came back. I found it by lining up the database rows against the analytics timeline after the fact, not by reproducing it live, and the fix sat on the front-end callback, not the engine.

The other recurring one is drift between the two halves. The engine expects the front end to fill in a piece, the front end has never heard of it, and a placeholder ships inside a real proposal. The lesson, written down so I stop relearning it: a comment is not a contract. The only thing that holds two systems together is a test that fails the moment the wire between them changes.