OneProposal
BuildingTurns the context of a freelance project into a finished, client-ready proposal, written in your voice.
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.
- Moved the strongest model to the default for drafting and kept the cheaper one for refine and follow-up, so quality goes where it matters and cost stays in check.
- Ran a two-track audit of the whole system and worked the findings. A first tester paid for a credit and got a proposal out the far side, which proved the payment and cost path. Shipped a refine step, a follow-up email generator, and richer research output, each with behavioral tests.
- Quiet launch to friends and family. Flipped payments to live mode, moved onto its own domain, wired analytics and an in-app feedback widget, and shipped credit purchase plus a batch of readiness fixes in one go.
- Made live research a hard requirement, so a proposal has to be grounded in real signals about the client instead of invented ones. Shipped a cleaner editorial template and verified it end to end.
- Closed a productization sprint. The engine now returns a finished one-page proposal, not just text, and gained a way to regenerate it from a different angle. Moved off the heavier agent framework to direct model calls, which cut the cost of a draft by roughly ten times.
- Started building the proposal engine.