We recently built ourselves a proposal system. Not because the world needed another one, but because we wanted something that worked exactly the way we work. It’s not something we’d ever sell or share. It’s just a simple internal tool, built for a team of a few people, and that turns out to be the whole point. We call it Sparrow.
Proposals, the way we write them
Over the years we’d noticed that our proposals are mostly made of the same ingredients, rearranged. An introduction. A description of the work. Some relevant case studies. Pricing. The off-the-shelf tools we tried always wanted us to start from scratch, or fight a template, or pay for a pile of CRM features we’d never touch.
So our tool is built around reusable blocks. When we put together a proposal, we’re mostly toggling things on and off: this case study, not that one; this service, at this tier. We keep a pricing matrix of our services, and since we’re in Portland, the tiers are named like espresso orders: Single Shot, Double Shot, Triple Shot. A proposal comes together in minutes, and every one of them looks like us.
Some of the details are the kind of thing you only get when you build it yourself:
- Every proposal gets a clean public link we can send to a client: no login, no account creation, no friction.
- Clients can view pricing in the currency of their choice.
- They can pick the options they want right on the page, see the totals update, and accept the proposal then and there.
- We can see when a proposal has been viewed, which is quietly one of the most useful features. No more wondering whether it landed.
- There’s a nicely formatted PDF a click away, for the clients who want to forward something around internally.
Credit where it’s due: we built this with a lot of help from Claude Code. But the interesting part isn’t how it was built. It’s what happened after.
The part where we didn’t want another tool
Here’s the thing about internal tools: every one you build is another place you have to remember to look. And we didn’t want that. We wanted to build and share beautiful proposals. We did not want to adopt Yet Another Tool for tracking them.
Our whole working life runs through Basecamp. Projects, to-dos, client conversations: it’s where we already are, all day. We were even tracking prospective work on a Basecamp card table before any of this existed.
So instead of building tracking into our proposal tool, we pointed the tool at Basecamp.
Now, when someone fills out the inquiry form on our site, our app does a first pass for us. It vets the inquiry to see whether they’re a reasonably good fit, does a bit of research on them, and then adds a card to that same Basecamp card table with what it found, including a suggested reply and a sensible range for the proposal. By the time one of us sees the card, the homework is already done.
When we send a proposal, the card gets a link to view (or edit) it, right there. And when a client accepts (hopefully) the card moves to the right column and updates itself. Nobody has to remember to do it.
The result is that we spend all our time and focus in Basecamp, same as ever. The proposal tool just quietly does its job offstage. It doesn’t feel like a separate app; it feels like an add-on to Basecamp, an extension of a process we already trusted.
This is becoming a habit
We’ve built a few of these now. I’m working on another one at the moment, for making really nice style guides for the clients we work with. Same idea, same shape: a small, focused tool that does one thing beautifully and hands everything else back to Basecamp.
I love tinkering on these. Part of it is just that iterating on your own tools is fun. But the deeper satisfaction is that they fit. Each one slots into our workflow instead of demanding we adopt a new one.
It feels like cheating
There’s something liberating about making software that’s only meant for your own team.
You skip so much. No settings pages for preferences you don’t have. No onboarding, because everyone who will ever use it sits in the same (virtual) room. No generalizing for customers with different needs, because there are no customers. When a feature only makes sense for the way we work, we just build it that way.
It feels like cheating, because it brings so much clarity and simplicity. The tool can be opinionated in all the ways commercial software can’t afford to be, and every opinion is ours.
For a long time, this kind of thing was hard to justify. Custom internal software was something big companies did, and small studios made do with off-the-shelf everything, bending their process around their tools. That math has changed. A small team can now afford to build tools shaped precisely like their own process. Keep them small, let them live inside the tools you already love, and they don’t add weight. They remove it.
We just wanted to send better proposals. What we got was a way of working where the software finally bends around us, instead of the other way around.