How a solo builder did SE without a team, a budget, or a formal process. The methodology behind every feature that shipped.
Part of the ForkIt! Case Study. Read the full story →
SE is not a role or a budget line. It is the discipline of learning what someone needs by paying attention to what they do. If you've ever watched someone struggle with a tool and thought "that should work differently," you've done stakeholder engagement.
The scale is different. The principles are identical: identify who's affected, learn what they need, close the loop.
Five types. Each requires a different collection method, a different weight, and a different response.
Swipe or use arrows
Engagement has a consent dimension. Knowing what to ask is only half of it. The other half is knowing when, and when not, to ask.
I made someone mad by picking the wrong time to test. They were willing to help, just not right then. I didn't read the room.
Lesson: engagement requires consent. Even with friends and colleagues, "can I show you something?" is a question, not a command.
Hostel strangers at a communal dinner table couldn't easily leave. That's a captive audience, and captive testers behave differently from voluntary testers. The feedback was still valuable, but the power dynamic mattered.
Lesson: be aware of when the dynamic works in your favor. It doesn't make the feedback invalid, but it changes what the feedback means.
How many questions are too many before you're a nuisance? More than two. One focused question per encounter beats five scattered ones. Get in, observe, get out.
Lesson: the best SE moment in this project was one where I said nothing. I just watched someone use the app and wrote down what they skipped.
"I want ANYTHING BUT Indian food. That's what we eat all day."
Raw input. No interpretation yet. A guy at a hostel dinner table, frustrated, hungry, and very specific about what he didn't want.
Separately, a Reddit user got sent to a gas station that gave them food poisoning. Same underlying need, different source: the ability to exclude places.
The request is an exclude filter. The need is deeper: picky eaters define preferences by rejection, not selection.
The product insight: the app assumed users know what they want. This user knew exactly what he didn't want.
Does it reduce friction? Yes. Does it reduce decision fatigue? Yes. Does it introduce new stress? No; it's one text field. Cost: minimal (client-side filter on existing data).
Ship it. Same session, same day. The exclude filter went from observation to working feature in hours.
The hostel group used it immediately. The guy got Thai food. The loop closed in real time, at the same dinner table where it started.
Total time from stakeholder input to shipped feature: one evening.
Not every feature closes in one night. The Group Fork feature took the same five stages across weeks.
A Reddit user asks: "Add a check-in feature. Notify your friends list when you're at a restaurant."
Meanwhile, vehicularmcs sends a DM: "For years I have wanted a lunch-as-social-media app. Show me where my friends are going."
Translation: not "notify friends where I am," but "I want to make it easier to eat with friends right now."
A check-in feature means a friends list, location tracking, persistent data. Privacy liability. Scope explosion. The request doesn't align with the vision.
The need does. Kill the request. Ship the need as Fork Around.
Back to the Reddit thread. Back to beta testers. Did this actually solve it?
Same pipeline. Different timescale. Same discipline.
Enthusiastic feedback from mom groups sounded great. See 'n Say imagery, kid-friendly features, gamification. They'd absorbed their kids' marketing and regurgitated it as feature requests.
The imagery locked me into the wrong mental model for weeks. Real users under real stress (hostel strangers, hungry and impatient) broke me out.
Cost: Wasted design cycles on a direction that didn't serve actual users.
Lesson: enthusiasm is not signal. Ask "who benefits from this feature?" If the answer is someone who won't use the app, deprioritize.
Work trip. Restaurant. Perfect moment to show someone what I'd built. The engagement moment was right; the preparation was wrong. I was on a dev build. The backend had been updated without my realizing it.
App wouldn't work. Couldn't pick a restaurant. At a restaurant.
Cost: Three potential users lost that night.
Lesson: every demo is a stakeholder touchpoint. Treat it like one. Test on the device, in the environment, within the hour.
Had promo codes for early adopters but no systematic way to identify and reach them. Some of the highest-value testers (hostel strangers who gave the exclude filter feedback, the walker who surfaced the walk mode gap) were already gone.
youthfulgoon loved the concept. sbg4life22 related as a lapsed developer. TerribleInspector707's wife was tired of him asking. All were alpha testers. None could be reached for follow-up when Group Fork shipped months later.
Cost: Lost the ability to close the loop with the people who shaped the product most.
Lesson: capture contact information during engagement, even informally. A first name and a way to follow up is the minimum viable stakeholder register.
These don't exist for solo builders. So here's what I would have used, described well enough that you could build your own.
Hover over (or click) a card to see what went wrong without it.
Before approaching anyone: What am I testing? What's the one question? What does success look like? What's my exit if the timing is wrong?
For every piece of feedback: Who said it? What's their context? Are they a user or a bystander? Is this a need or a request? Does it align with the product vision?
Not a formal register. A list: who gave feedback, what kind, when, and whether the loop was closed. First names and a note about context.
Before any stakeholder touchpoint: is this a production build? Has it been tested on this device in the last hour? Do I have a fallback if it crashes?
Stakeholder engagement is not a role, a budget line, or a formal process. It is the discipline of learning what people need by paying attention, asking the right questions, and closing the loop.
A solo builder doing this informally is doing the same work that a program with a stakeholder register does. The scale is different. The principles are identical.
The people who used this app didn't know they were stakeholders. They were just hungry. The ones who shaped it the most were the ones I watched, not the ones I asked.
Quotes from real stakeholder conversations. Names are Reddit usernames; emails redacted.