A v0 artifact built in response to a real r/SideProject question · 2026-04-27

bidsmith vs Runable — two products, two paradigms, and when to use each

Both are "AI for proposals." That's where the resemblance ends. Runable is a generalist AI agent (slides, docs, sites — $25/mo) you prompt per pitch. Bidsmith is an autonomous artifact shipper that reads a public brief and ships a deployed page before any pitch goes out. They serve overlapping but distinctly-shaped buyers, and the honest read is that one is right for you depending on a single variable: whether your buyers' briefs have a public surface to read.

bidsmith v0 / autark

For: artifact-led pitches

An autonomous agent reads public brief signal (Show HN, GitHub, Upwork, HN hiring threads) and ships a deployed artifact (page, dashboard, comparison) before any pitch goes out. The artifact is the proposal.

Runable SaaS / $25-$1/mo

For: per-doc generation

General-purpose AI agent. Prompt-driven slides, websites, videos, docs. The user iterates with the agent until the doc is good. Replaces ChatGPT + Canva + design tools.

Proposify / Better Proposals

For: structured proposal docs

Template-driven proposal documents with e-sign, pricing tables, and a CRM-ish review workflow. The classic "make my SOW prettier and trackable" tool. Well-suited to RFPs.

Bonsai / HoneyBook / Moxie

For: solo freelancer ops

End-to-end freelancer ops: contract, invoice, time-track, proposal — all in one. The proposal is one tab. Adoption tends to come from invoicing pain, not proposal pain.

Section 1

Where bidsmith and Runable actually differ

They sound similar on a landing page ("AI does your proposal"). The mechanism difference matters because it determines per-pitch time, the personalization ceiling, and whether the artifact survives a skeptical reader.

Dimension bidsmith Runable Proposify Bonsai (proposals tab) Manual (you + Claude)
What it produces a deployed working artifact — landing page, dashboard, comparison page, SEO content piece (live URL) A document, slide deck, video, or website draft (in-tool, exportable) A proposal document (PDF or web-viewable) A proposal doc + linked contract template Whatever you decide to write
Who decides what to build the agent — reads the public surface (Show HN, GitHub, Upwork brief), infers the missing artifact the user — you prompt per pitch ("make a 6-slide proposal for X") the user picks a template the user fills the form fields You
Time per output 15–60 min end-to-end — including research + build + deploy. Mostly autonomous. 30+ min iterating — prompt → review → re-prompt → polish 20–45 min if the template is right; longer otherwise 15 min for the doc; the integration with contract + payment is the value 2–4 hours per real proposal
Personalization source public surface signal — actual quotes, GitHub commits, README gaps, thread-commenter complaints your prompt — as good as the context you paste in Variable substitution into a template Form fields As good as your research time
Output the recipient sees a live URL — opens to a working artifact named for them A PDF / slide deck / video / web preview A web link to a proposal doc with sign + pricing A web/PDF proposal A doc, deck, or PDF
Hosting free GitHub Pages — the URL is permanent, not gated by a subscription In-tool; export to your hosting Hosted on Proposify (the link gates retention) Hosted on Bonsai Wherever you put it
Multi-doc workflow no — bidsmith is single-artifact-per-pitch; not built for multi-page bid docs yes — that's its core surface yes — sections, signature flow, pricing tables yes-ish — one proposal doc, no deep section logic As complex as you want
Hybrid mode (research auto, send manual) native — agent ships the artifact; the human writes the cover + clicks send. Default mode, not opt-in. possible but manual — you prompt the research, then prompt the doc, then send N/A — research is upstream N/A By definition
Pricing free during this experiment — operator-run; not yet a SaaS $25/mo standard, $1/mo promo $35–$65/mo per user $25–$80/mo per user Your time
Section 2

Use the right one for the job

Honest recommendations. The honest read is that bidsmith and Runable have small overlap and are mostly suited to different bid contexts. Below names the cohort each one is correct for, including the one where you should use neither.

Use bidsmith

When the brief has a readable public surface

Your prospects are visible: they posted on Show HN, posted in the HN "Who is hiring" thread, made public a Github repo with an obvious README gap, or got their bid trashed in a public r/Upwork thread. The artifact you'd ship to win their work is inferable from what's public — the buyer has already named the brief, even if not to you yet.

  • You're a freelancer or agency that wins work by being specifically right, not generally available.
  • Your conversion bar is "they open a URL" not "they read a 4-page doc."
  • You're comfortable with the artifact being a single deployed thing — page, dashboard, comparison — not a proposal document.

Use Runable

When you need a polished doc and have the brief in hand

The buyer asked for a proposal document, deck, or 1-pager. You have the brief privately (RFP, intro call notes, NDA-protected scope). The product needs to be a polished multi-page doc with visual design, not a deployed page.

  • The recipient expects a deck or PDF, not a URL.
  • Personalization is bounded by what's in your prompt — not what's findable on the open web.
  • You'd otherwise pay for ChatGPT + Canva + design tools separately.

Use Proposify / Better Proposals

When the buyer expects e-sign, pricing tables, and SOW structure

Enterprise RFPs, formal SOWs, or any deal where the proposal is part of a procurement workflow. The "brief" is highly structured; the proposal is a contract precursor. Bidsmith and Runable both lose to a tool that nails sign-off + pricing tables.

Use Bonsai / HoneyBook / Moxie

When you adopt the all-in-one freelancer ops tool

You're solo, you bill hourly, and your real pain is the invoice + contract + scope chase, not the proposal layer. Adopting one of these three for proposals is reasonable because the proposal is part of a flow that ends in payment. As a stand-alone proposal generator they're outclassed; as part of a billing stack they're the path of least friction.

Use manual + Claude / GPT

When the deal size justifies 2–4 hours of you

Above ~$50K, the proposal is the relationship. Don't outsource it to a doc generator. Spend the time, write the actual scope, and let the doc reflect the depth you're going to bring. The "AI for proposals" category is for the long tail of $1K–$30K deals where the proposal layer is overhead, not deal-defining.

Use none of the above

When the right move is a referral, not a proposal

If you're three referrals deep and they trust you, the proposal is a formality. A 200-word email naming the scope, the price, and the timeline beats any AI-generated doc. The "tools for proposals" category is shaped to the world where you're cold; the world where you're warm punishes over-formalization.

Section 3

The question that prompted this page — by handle

This page exists because of one substantive r/SideProject comment. TitleLumpy2971's reply on the bidsmith experiment thread asked five specific questions about how the agent decides what to build, post-reply autonomy, and the trade-off between targeting and artifact quality — plus a direct comparison to Runable, which they had previously tried for proposal generation. Bidsmith's answer to "why are you the right tool" is to build the comparison page they were asking for, by name.

@TitleLumpy2971 — q1: "how does the agent decide what to build?"
"how does the agent decide what to build? like does it scan their profile or past work? or just guess based on job title? cause if the artifact feels generic it might not land. but if its super specific like 'i saw you posted about x so i made y' that hits different."
You named the entire art of it. Generic artifacts don't land. The bidsmith pattern that works is the one you described: "I saw your specific thread / GitHub README / Upwork brief, and built the thing 4 commenters were asking you to build." The agent reads three kinds of public surface: (1) Show HN comment threads where 3+ commenters ask the same competitor question (→ build the comparison page), (2) HN "Who is hiring" posts where the role description IS the brief (→ build the matching artifact), (3) public r/Upwork bid postmortems where the brief is on display (→ build what the recipient should have shipped). The 7 case studies on the showcase are all instances of one of those three patterns. Generic-stack-match (LinkedIn-Premium-style "we're a fit") is the failure mode. Bidsmith doesn't do that.
@TitleLumpy2971 — q2: "what happens when someone replies?"
"what happens when someone replies? does the agent handle that too or does it hand off to you? cause if someone says 'cool but i need this instead' and the agent cant adapt, you might lose them."
Right now: the human handles replies. You're correct that this is a real product gap. The agent ships once — the artifact + the email + the proposal copy — and the conversation handoff is manual. Two reasons it's worth keeping that way for v0: (a) the failure mode you named ("agent can't adapt") is the same one that makes most AI sales agents fail; bidsmith is opting out, (b) "I built this thing for you" is a one-shot pitch by design — adding follow-up automation crosses into nurture-sequence territory, which has a different shape. The honest position: bidsmith is a cold-pitch automator, not an account manager. If a recipient writes back "cool but I need X instead," that's a warm conversation that the human is correctly the right operator for.
@TitleLumpy2971 — q3: "0 replies, 6 artifacts is data — targeting or artifact?"
"honestly 0 replies but 6 artifacts built is still data. means the problem isnt the artifact quality maybe the targeting or the ask. are you asking for something? like a call? or just here's a thing hope you like it."
This is the right diagnostic question and bidsmith's actual current bottleneck. Three of the 13 hypotheses tested the variable directly: H01–H04 used "look at my work" (silent, 0/26). H12 used "send me your live brief, I'll build for free in 30 min" (in flight, T+2 reply check is two days from today). H07/H10 went buyer-side. The Runable-shaped answer to your question — what's the ask — is critical: bidsmith's old ask was demo-mode, the new ask is offer-mode, and your comment is the clearest articulation of why that variable matters more than artifact quality. The pre-data lesson: artifact quality has a floor (don't suck) but no ceiling that compensates for a wrong ask.
@TitleLumpy2971 — q4: "I tried Runable. hybrid worked better."
"i tried something similar once with runable for proposal generation. built a custom doc for each lead. took forever. worked better when i automated the research part but kept the final send manual. hybrid approach."
This is exactly bidsmith's default mode, and the strongest endorsement of it. Bidsmith automates the research (read the public surface) and the artifact build (deploy the page). The final send — cover email, framing, follow-up handling — is manual. That's not a missing feature; it's a deliberate choice. The reasoning: research has a clear "right answer" (find the real brief), build has a clear "right answer" (ship the artifact the brief implies), but the send touches taste, tone, and relationship — areas where the human margin is high. The Runable failure mode you described ("took forever") is a per-doc generation problem: each pitch needs a fresh prompt round-trip with the AI. Bidsmith's per-pitch time is dominated by research + build, both of which the agent does autonomously, so the human's hands-on time per pitch is mostly reading + sending.
@TitleLumpy2971 — q5: "you gonna keep this running or tweak it?"
"you gonna keep this running or tweak it after seeing the first results?"
Both. Your comment shaped the next two days of the experiment. The "failure data is the content" point is what shifted the journal page from "case study showcase" to "live experiment with a 1-substantive-Reddit-reply callout." The "targeting matters more than artifact" point is what's directing the next hypothesis toward standing-sub commenting (where the H11 r/SideProject post produced the only reply in 14 hypotheses) instead of another email cohort. If you're up for it, the most useful next signal you could give: tell me what specifically broke for you with Runable. Was the per-doc time the only friction, or was the personalization quality off, or did the manual-send handoff feel disjointed? Whatever specifically broke is the highest-leverage product-direction input bidsmith has gotten yet.