Keeping a project car’s context together.
I co-founded Assembly with Tom and built most of the product. The work combines project-car context, customer feedback, and hands-on implementation across web, iPhone, and iPad.
Co-founder & hands-on builder
Project car hub
Web, iPhone & iPad live
Problem: Build context scattered across notes, spreadsheets, photos, and receipts.
My contribution: 80%+ of the build, by my own estimate; discovery and testing shared with Tom.
Key choice: Flexible writing with linked parts, instead of a rigid build sheet.
Shipped: A live multiplatform product and the revised Spec experience.
Next: Use feedback to prioritize useful owner tasks; Android is coming soon.
The scattered context
A project car’s history rarely lives in one place. Plans end up in Notes or on a whiteboard. Parts live in a spreadsheet. Photos, receipts, and files accumulate elsewhere. Each tool is useful, but the connections between them are easy to lose.
Assembly organizes that context around a vehicle and its projects. The goal is to make it easier to return to a build, understand what happened, and decide what to do next.
Feedback reinforced that premise. Owners wanted easier web data entry; seeing tasks helped some resume after time away. Others still kept maintenance in Notes. Those observations were direction, rather than evidence that everyone worked the same way.
A rigid Spec met a real expectation
Early feedback showed that the structured build sheet made people stop to think about how to enter their car. One tester expected open writing like the project Plan, with parts mentioned directly in the text.
That exposed a useful tradeoff. A fixed schema kept information organized, but fought the way an evolving build was described. Plain text felt natural, but could lose the relationships to catalog parts.
| Keep | Change |
|---|---|
| Connections to catalog parts. | Requiring a rigid form to describe the build. |
| Useful part previews in context. | Make Spec a flexible note that owners can write naturally. |
Working with Tom, I built a prototype that embedded linked part previews in notes. I then used that approach for a more flexible Spec. The implementation retained the useful relationships while fitting the way owners described their cars.
The revised Spec was implemented. We did not establish a quantified usability lift for this change.
Desktop planning, garage capture
Multiple beta users asked for desktop support for longer data entry. That mattered: planning a build and recording a moment in the garage are different situations.
The live product now supports web, iPhone, and iPad. The web experience gives owners room for plans and files; the mobile experience keeps project context available around the car.
Parts have a practical lifecycle: to buy, on shelf, and installed. Photos, documents, and CAD previews stay tied to the car rather than becoming a disconnected folder.
My part, and the shared work
Tom and I share the product work. Tom contributed discovery and testing; I concentrated on building. My estimate is that I completed more than 80% of Assembly’s build.
That estimate describes my personal contribution to the build, rather than sole ownership of the product’s decisions. The Spec prototype and its implementation are concrete examples of my hands-on contribution.
This is the kind of work I enjoy: connect an observation to a product choice, build something people can use, and bring what happens back into the next decision.
What we can say today
Assembly is live on web, iPhone, and iPad. The flexible Spec and linked part previews are implemented. Android is coming soon; maintenance and service reminders remain roadmap items.
“This is literally what we have been needing for our projects.”
RyanVerthein · App Store review, Aug 14, 2026 · Public review
A review is one person’s feedback. The stronger execution evidence is the live product and the specific improvements made from testing. We have not established a conversion or retention result for this change.
The next product question
A September 2026 survey of 38 respondents pointed more toward useful owner tasks (cost tracking, parts research, and importing history) than toward an explicit AI or MCP interface. It was a small, directional sample, not a market estimate.
That helps frame the next question: where can Assembly remove work and keep context connected? Technology can support those tasks in the background. It doesn’t need to become the reason an owner uses the product.