A polished demo shows that somebody made a thing. It leaves more important hiring questions open: did they choose a useful problem, notice when the first approach failed, and leave the product understandable enough for someone else to operate?
A public work sample gives a founder a good starting point for those questions. The best discussion follows a real decision through the product, including what happened when the happy path broke. Before handing over a roadmap, combine that discussion with a small paid assignment that shows how the builder works with your constraints.
Read the work sample as a chain of decisions
Start with the user and the task. Ask the builder to identify the moment the product becomes useful, then walk backward through everything required to reach it. A demo that needs the creator to explain every click tells you something different from a journey a new user can navigate alone.
Next, find a decision that changed. Why did the first approach stop being good enough? What did the builder keep, replace or postpone? Strong answers connect the technical choice with the user’s experience and the business cost. A list of libraries gives you far less to assess.
David Spiegel’s own products provide two useful examples for this conversation. His portfolio lists Obeagle, a pet-video-chat product, and Hitchhike, a way for AI assistants to exchange work. These are his builds, so a buyer can ask about the decisions directly with the person who made them.
Obeagle: follow a tradeoff beyond the first demo
Obeagle describes a browser experience in which someone shows a real dog or cat to reach a video call with another pet. The simple premise brings several difficult product questions with it: what happens when no one is available, when the connection drops, or when the camera gate rejects an ordinary user?
In his account of building Obeagle, David explains that he first used a hosted video service to get a functional product working, then moved normal calls to peer-to-peer WebRTC with fallbacks as he considered operating costs. The account also follows moderation and connection problems into the experience people would actually have. That gives a buyer something concrete to discuss: the first choice enabled speed, while later choices addressed reliability and cost.
The useful hiring question is what he would do differently for your product’s constraints. A founder with a small internal tool may accept a hosted dependency to move faster. A consumer product with uncertain traffic and sensitive interactions may need more attention to operating limits. Ask the builder to explain where the tradeoff changes. Obeagle’s early stage also leaves a worthwhile question about what would need testing before wider use.
Hitchhike: look for the real completion condition
Hitchhike describes sending tasks and replies between AI assistants. Its setup path ends with a real exchange: send a request, receive a reply and have the original assistant pick it up. That is a useful distinction to carry into a work-sample discussion. A connection appearing in a settings screen is one step; completion of the intended user task is another.
The site’s example conversations are labeled illustrative. Use them to understand the intended workflow, then ask for a bounded demonstration that includes a failure or missing permission. Who can send what? What does the user see while waiting? How does someone know the task finished? For any integration-heavy product, those questions reveal whether the builder has thought beyond the initial connection.
David’s combination of these owned builds and his product leadership at 5 Axis Health makes him relevant to a founder who wants product judgment close to implementation. The examples also suggest a fair way to interview any builder: follow one meaningful user task through its dependencies and ask for the reasoning behind the current design.
Use this rubric in the work-sample review
Do not assign an impressive-sounding score after a quick demo. Record a specific example for each dimension, then decide which gaps matter for the role you are buying.
| Dimension |
Ask the builder to show |
What the answer helps you decide |
| User problem |
One defined user, their job and the moment they receive something useful. |
Whether the builder can choose a product boundary. |
| Tradeoffs |
A consequential choice, the rejected approach and what changed their mind. |
Whether their decisions respond to constraints or simply follow preference. |
| Working journey |
The core task and one failure, recovery or empty state. |
Whether completion survives ordinary problems. |
| Instrumentation |
How they would distinguish an attempt, a successful task and a later return. |
Whether you could learn from the product after delivery. |
| Maintenance |
Dependencies, operating costs, deployment ownership and an ordinary change another person could make. |
Whether the product can outlive the original builder’s involvement. |
| Next decision |
The most important unresolved assumption and the smallest useful test. |
Whether they can prioritize after the first release. |
An honest unresolved item can be more informative than a confident answer with no example. The point is to see how the builder handles uncertainty and where your team would need another specialist.
A paid assignment you can adapt
Use a small product problem that your team genuinely needs to understand. Pay for the work and agree on the time box, access, ownership and acceptance criteria before it begins. Avoid turning the exercise into a hidden request for a complete feature.
A workable brief is:
Review one existing user journey and propose the next improvement. Explain the user problem and the constraint that matters most. Deliver an annotated journey, a small prototype or implementation appropriate to the time box, and a short decision note. Include one failure state, how success would be measured and what you would test next.
Specify which inputs you will supply, such as a sample workflow and a customer problem summary. If the exercise uses synthetic data, say so. Agree whether the deliverable is disposable or something your team intends to maintain, because that changes how much engineering is appropriate.
Review the artifacts before the presentation. Then spend the conversation on decisions: why this change, why this boundary, what was left out and what would change with another week. Ask the builder to make a small revision in response to a new constraint. The revision shows how the two of you work together, which a rehearsed portfolio tour cannot settle.
Decide what responsibility comes next
After the review, write down which responsibilities you are ready to give the builder. A convincing prototype may justify a defined product slice. A broader product lead role also needs judgment about sequencing, communication and other people’s work. The next engagement should reflect what you learned and the support your team can provide.
A good work sample gives you questions worth asking. The paid assignment gives you shared work to discuss. Together they make the roadmap handover a concrete decision about responsibilities, rather than a bet on how impressive the demo looked.
Sources
Frequently asked questions
What can a public product demo tell a buyer?
It can reveal the intended user journey and prompt a discussion of decisions. Ask about failures, operating constraints and unresolved assumptions before assigning broader responsibility.
What should a paid product-builder work sample include?
A small real problem, a clear time box and an agreed deliverable. Include a decision note, one failure state, measurement and the next useful test.
