Most startup advice sounds good until you actually start building
One thing I’m realizing while building VIDI:
A lot of startup advice only makes sense under stable conditions.
Early-stage building usually isn’t stable at all.
You’re making decisions with:
incomplete information,
limited resources,
unclear demand,
and constantly changing assumptions.
Which means a lot of the game becomes:
observing behavior,
adjusting quickly,
and learning faster than your previous assumptions break.
What surprised me most over the last 11 weeks is how often user behavior changes the direction of the product more than the original idea itself.
Not because the original vision was “wrong.”
But because reality is usually more nuanced than the theory you start with.
Still early.
Still learning every week.
Curious how many other founders experienced a major shift between:
what they thought they were building
vs how people actually ended up using it.
This hits hard. The advice that "do things that don't scale" or "talk to your users" sounds obvious — but when you're actually in it, you're spending most of your energy just figuring out if the problem you're solving is even real. I'm building a habit app right now and the hardest part isn't the code or the design — it's resisting the urge to apply "scale-up" thinking to something that still needs to prove itself at the smallest level. The instability you describe is real, and I think the builders who survive early stage are the ones who get comfortable making decisions without enough information. Great post.
I think there’s a balance though. Early stage sometimes requires pushing through uncertainty long enough to know whether the problem is actually structural or just part of the process.
Exactly, people do not care what you build or what that app have and can do, they care only about final results for them. If they do not see that in first 15 sec, change something.
At least it was case for my app DevTet monitoring for websites, people want results nothing else. You can have many feuters, but if they do not see value in first 15 sec, no point.
Yes, I agree, but it works a bit differently.
the "stable conditions" framing is the clearest way i've seen this put. most startup advice is calibrated for the growth phase — when you already know what the unit of value is and you're trying to produce more of it.
early stage is the opposite: you don't know what the unit of value is yet. so advice like "double down on what's working" assumes you can already tell what's working, which is exactly the thing you're trying to figure out.
the mental shift from "executing a plan" to "running cheap, fast experiments to find out which plan is worth executing" changes everything — which metrics feel useful, which conversations feel worth having, which decisions can wait.
That’s very true. Early on it feels less like “building a company” and more like compressing years of learning into a much shorter period of time.
The compression feeling is real. The silver lining is that the learning actually compounds — each hard lesson makes the next iteration faster. Most of what feels like failure in year one is just table stakes for being able to move with real confidence in year two.
When you start building, you learn faster than any books or recommendation or advice can ever give you.
Honestly, this founding journey has 10x'd my speed of growing, growing older faster but also learning more quicker
Yeah, I relate to that a lot. Building something in the real world compresses learning in a way that’s hard to get from theory alone.
This hits close to home. I built ProposalGen (AI proposal generator for freelancers) expecting the primary user to be web developers and designers — that's who I was thinking about when I built it.
Turns out the heaviest users early on were photographers and consultants. People whose proposals are really relationship documents more than technical specs. I hadn't written the UI language with them in mind at all, and I had to rethink several copy decisions because of it.
The frustrating-but-useful thing you describe — user behavior changing direction more than the original idea — I'd add that it usually only surfaces once someone who isn't you uses it under real conditions. The first 10 users who aren't friends will teach you more than months of planning. Still processing what the next round of adjustments needs to be.
Appreciate you sharing that 🙌 real-world usage patterns often end up revealing a much different audience or workflow than the original assumptions.
You're welcome :)
The 11-week mark is interesting because it's when the original
assumptions usually break in ways the 4-week or 8-week marks
don't show. Saw this on a project I worked on this year:
founder was certain the value was in the analytics layer. Users
kept gravitating to one small compliance feature. He fought it
for a month before letting the product follow the actual
behavior.
The hard part isn't seeing the signal. It's letting go of the
original framing fast enough to act on it.
Worth asking yourself: of the things users are doing in VIDI
right now that don't match your original spec, which one are
you most tempted to "fix" back toward the original vision?
That's usually the signal.
Interesting perspective 🙌 but some of the more specific workflow shifts and behavioral patterns are probably something I’d rather keep private for now while things are still evolving.
This resonates deeply. The gap between what you think you're building and how people actually use it is where most of the real learning lives. Early users don't care about your vision. They care about their problem. And their behavior will tell you exactly what to build — if you're willing to listen instead of defend the original plan.
The founders who win aren't the ones with the best initial idea. They're the ones who can observe reality, kill their own assumptions quickly, and pivot without ego. You're describing exactly that muscle. Keep flexing it.
Appreciate it 🙌 yeah, real-world behavior often ends up teaching much more than the original assumptions do.
The advice that surprised me most: check what AI says about your product before you launch.
Most founders set up Google Search Console. Almost no one audits what ChatGPT/Perplexity says about their category before they go live.
Those LLMs have opinions — formed from training data, not live crawling — and they're forming those opinions whether you're aware of it or not. I've seen founders discover ChatGPT was recommending a competitor when their product was better, simply because they weren't in the training data sources LLMs weight (G2, Capterra, forum threads, blog comparisons).
The lesson for me: validation isn't just about whether humans want your thing. It's whether the AI layer that mediates discovery even knows you exist.
I think discovery can come from a lot of very different channels depending on the product, market, timing, and user behavior - not just AI search layers alone.
This is the part of building I underestimated most: advice often sounds contradictory only because it skips the question of what constraint you are actually facing right now.
If the bottleneck is demand, “ship faster” can be noise.
If the bottleneck is activation, “talk to more users” may not be enough.
If the bottleneck is retention, more acquisition just pours water into a leaky bucket.
The hard part early on is not only learning fast — it is diagnosing which kind of learning matters next.
Interesting perspective. I think early-stage constraints can definitely become much more contextual and dynamic than most general advice frameworks assume.
This hit close to home. I built 6 tools over the last year and every single one shifted from the original spec once real users got involved — not dramatically, but enough that if I'd locked in on the first version I'd have built the wrong thing.
The one that surprised me most: I assumed the hardest feature request would be around routing or scheduling logic. Turned out the thing users kept asking about first was proof-of-work documentation — photos, timestamps, job notes. Something I almost skipped entirely because it felt secondary to the "main" feature.
Your point about stable vs. unstable conditions is exactly it. Most advice assumes you've already found signal. Early stage you're still trying to figure out what signal even looks like.
Still 11 weeks in for you — that's prime territory for exactly these kinds of redirects. Keep paying attention to what people do, not what they say they want.
Appreciate you sharing that 🙌 and yeah, real-world usage often ends up reshaping what initially seemed “secondary” versus core much more than expected.
"Exactly — and the humbling part is it usually takes longer than you expect to see it. You watch the data for weeks thinking 'okay, this will confirm my original assumption' and then it just... doesn't. The product you ship and the product people actually use end up being two different things. That gap is where the real building happens."
Yeah, sometimes the gap between the original assumption and actual usage ends up being much larger than expected.
The advice-to-reality gap is so real. I spent weeks overthinking my stack before shipping anything, and honestly the "wrong" choice I made early on taught me way more than any framework ever would.
Yeah, real-world iteration usually teaches things much faster than theory alone can early on.
Major shift here too. Started out thinking I was solving a translation problem. Watching actual users showed me the real issue was something else entirely. People did not need better English. They needed their actual thinking and personality to survive the conversion process without getting smoothed out by tools. Completely different product thesis than what I started with. User behavior is the best product roadmap. The problem is you have to actually watch them use it, not just ask them what they want.
Yeah, that’s a really interesting shift honestly. Real-world usage often reveals a much more specific underlying problem than the original assumption.
This is so real.
Early-stage building feels less like executing a plan and more like constantly correcting your assumptions based on what users actually do vs what you expected them to do.
I’ve noticed the same while building DocMetrics — the original idea was fairly straightforward, but the way people interpret “value” changes once they start interacting with it.
Curious what was the biggest “we didn’t expect users to do THIS” moment for you so far?
Appreciate it 🙌 but honestly some of the more specific user behavior patterns and internal observations are probably something I’d rather keep private for now.
The advice that actually moved the needle for service businesses: templatize your client agreements before you need them.
Most founders treat contracts as a one-time setup task. But every new client engagement without a clear scope-of-work is a slow leak. The first time a client says 'I thought this was included' and you have nothing in writing, you eat the cost or lose the relationship.
Practical advice: before you sign your second client, have a contract and a project kickoff SOP locked. Not a lawyer-written 40-page doc - just a clear 2-page scope with payment terms and what's out of scope.
Interesting perspective. I think a lot of operational lessons only become obvious once people start dealing with real-world client dynamics.
This resonates deeply. As someone running an AI tools directory, I see this pattern play out constantly — founders ship what they thought the market needed, and the market quietly tells them they were 30 degrees off. The ones who listen are the ones who survive.
The "observing behavior, adjusting quickly, and learning faster than your assumptions break" framework is spot on. It's not about abandoning vision; it's about letting reality sharpen it.
Curious about your specific shift with VIDI — what did you think you were building versus how people actually ended up using it? Those specific pivots are usually where the real insight lives.
Congrats on 11 weeks of real building, Meirambek.
Appreciate it 🙌 and yeah, I think a lot of those more specific shifts and internal observations are probably better kept private while things are still evolving.
i personally think its trail and error you have to lose to win learn from your losses this is so important in start ups
I think a lot of startup paths can end up looking very different depending on the founder, market, timing, and product dynamics.
The "stable condition" most startup advice assumes is that the industry you are disrupting actually knows where it's losing money. We found out the hard way they don't.
To answer your question about the major shift in how the product is used: We are bootstrapping an AI triage engine for property managers. Originally, we thought we were building a better tenant communication app. We assumed if we just gave tenants better drop-down menus, they could accurately describe a broken appliance.
Then real-world behavior hit us like a freight train. Tenants literally don't know what they are looking at. A tenant typing "AC is broken" triggers a $150 minimum dispatch fee for an HVAC tech to drive out, only to find out it was a $20 capacitor. We realized the entire real estate industry just accepts this "Truck Roll Tax" as a normal operating expense. We completely scrapped the communication app and shifted to a visual-first model. Now the tenant just snaps a photo of the data plate, the AI runs the diagnostic, and we know the exact part needed before anyone gets in a truck.
The biggest shift wasn't just the product—it was the user. When we stopped building a tool for "talking" and started building a tool that outright blocks unnecessary $150 service calls, our users shifted from annoyed property managers to enterprise lenders wanting to white-label our tech. Reality is definitely messier than theory, but it's way more profitable if you follow the bleeding cash.
Interesting shift honestly. Sounds like real-world usage ended up revealing a much more specific operational problem than the original assumption.
Exactly. It is funny how the biggest operational problems are completely invisible until you actually sit down and look at where the bank account is bleeding. Our code couldn't tell us that, only the P&L could. Since you are building in the contract space with VIDI, what was the specific operational problem that real-world usage revealed for you? Are people trying to manage their contracts in ways you didn't originally expect?
Yeah, some of the more specific workflow and behavioral patterns are probably something I’d rather keep internal for now while things are still evolving.
Totally fair! Gotta protect the secret sauce early on. Wishing you the best of luck with VIDI as those patterns keep shaking out—building in the dark is wild but it's the only way to find the real gold.
Appreciate it
The gap you're describing is the whole problem with most advice — it's directionally true and operationally useless. "Talk to users." "Find your niche." Sure. None of it tells you what to send, to whom, or what number means it's working. I spent three months following good-sounding advice and earning exactly zero before I realized I had no measurable input anywhere in the process. The advice that actually moved things was always the boring, specific kind: a quota, a script, a tracked reply rate. Vague advice is comfortable because it can't be proven wrong. Specific advice is scary for the same reason — it can.
I think a lot of startup building ends up being much more contextual than universal frameworks make it seem early on.
This really resonates. I’m building a tech product and the “stable conditions” point hit home early stage feels more like constant turbulence than a clean playbook. What I’ve seen too is exactly what you said: user behavior ends up shaping the product more than the original idea. It’s not that the vision was wrong, it’s that reality is messier than theory. Appreciate you sharing this makes me rethink how much weight to give assumptions vs. observed behavior.
Appreciate it 🙌 yeah, real-world behavior usually adds a lot more nuance once people actually start interacting with the product.
Everyone must understand building startup is like learning and living a new life. It can never be a theory. Will be great to understand your roadblocks
Yeah, I think a lot of the learning only really happens once you’re actually inside the process and dealing with real-world situations in real time.
The shift you're describing -- theory vs how people actually use it -- tends to be most visible at three moments: the first real payment, the first support message, and the first refund.
The payment tells you who the actual buyer is (usually not who you pitched). The support message tells you what the actual use case is (usually not what you designed for). The refund tells you what expectation broke.
Most teams extend the 'coming soon' phase to avoid these three moments. But that just delays the learning. The embarrassment or pivot cost is the same whether it hits at beta or at real launch -- it just hits softer at beta because there is no real money to refund.
We built under a lot of assumptions about who would buy our AI tooling suite and what they would do with it. Putting a real price on it and watching the actual checkout patterns taught us more in the first week than six months of waitlist signups had.
Interesting perspective. I think a lot of early-stage learning becomes much clearer once real-world usage and real stakes enter the picture.
The shift between "what you thought you were building" and "how people use it" — I'm bracing for exactly this. I'm about to put my project in front of users for the first time in a few days, and honestly the part I'm most curious (and nervous) about is which assumption breaks first.
Your point about advice only working under stable conditions hits hard. Most of it assumes you already know your user. Early on you're basically running experiments to find out who that even is.
11 weeks in and already pivoting on user behavior — that's encouraging to hear, not discouraging. Good luck with VIDI.
Appreciate it 🙌 and yeah, I think a lot of early-stage building ends up being much more experimental and nonlinear than people expect at first.
This resonates a lot.
I’m currently building an AI SaaS myself, and one thing I underestimated was how quickly assumptions collide with real user behavior.
You start with a clean vision in your head:
clear positioning,
clear use cases,
clear priorities.
Then real users arrive and suddenly:
the features you thought were secondary become important,
the things you considered obvious create friction,
and sometimes users find value in parts of the product you barely focused on initially.
I think early-stage building is less about executing a fixed plan and more about staying adaptable without completely losing the original vision.
Still learning that balance myself.
Very true. A lot of the real learning only starts once actual usage and behavior enter the picture.
The biggest shift I keep seeing is from “what should this product be?” to “what job did users already try to hire it for?” Once you notice that, roadmap decisions get less philosophical and more obvious.
Yeah, real usage tends to clarify things in ways early assumptions usually can’t.
The gap between advice and reality that hit hardest for me: 'build in public' assumes people will find what you build.
What nobody mentions: if AI assistants can't accurately describe your product, you're invisible to a growing slice of how people discover tools. ChatGPT, Claude, Perplexity - they're increasingly how indie product decisions get made.
We audited 3vo.ai's AI visibility a few weeks ago. The results were humbling. Key differentiators we'd worked on for months weren't being captured in AI responses at all. The framing that resonated with humans just wasn't reflected in what AI said about us.
The advice that actually changed our approach: assume you're invisible by default, and every distribution channel is a test. Some channels that felt 'right' on paper underperformed the scrappy ones nobody talks about.
Interesting perspective. I think distribution and discovery can end up looking very different depending on the product, market, and timing.
This really resonates. I'm building an AI tools directory (useaitools) from an internet café in China — budget is literally the $2 I pay for the hourly seat. What I thought would be a simple list of tools turned into something completely different after watching how users actually interacted with the search and category filters. They didn't want a directory — they wanted a way to compare tools side by side. So I scrapped the original design and rebuilt around that behavior. The original vision wasn't wrong, just incomplete. Reality always fills in the gaps.
Yeah, that’s a great example of how real usage can reshape the product into something much more specific than the original assumption.
This is a really good point. Validation first saves so much wasted time — learned this the hard way too.
Yeah, real-world feedback usually changes the picture much faster than expected once people actually start interacting with the product.
Yes - experienced this with Genvoxa. I built it thinking founders wanted a research tool to organize user interview transcripts.
Turns out the real use case was much simpler: founders finish an interview, feel good about it, then two weeks later can't remember what the user actually said. They weren't looking for organization , they were looking for a way to not lose insights they already had.
Same product, completely different problem. The original idea wasn't wrong but reality was more specific than the theory I started with.
Yeah, that’s a great example honestly. A lot of the time the real value ends up being much more specific and behavior-driven than the original framing.
Totally agree — I learned this the hard way when building my first product. Execution always reveals what theory misses.
Very true. A lot of things only become obvious once real users and real-world constraints enter the picture.
This comment was deleted 3 months ago.
Hi I know these area is for comments, but I need help from everyone. I am working on a project Uvilox AI and this is my Startup. As a founder of your own Company and as a user, I would like a honest feedback from you all.
This project is about using the AI on Calling and connecting with the person, Doctors even in abroad and getting the Medical Help. Create a mini Doctor in Home.
Just use the app in the web.
I would like a honest feed back and it would be of great help.
Thank You.
You’ll probably get much better feedback if you make this its own post with more detail about the actual problem, workflow, and who it’s for instead of dropping it into comments.
yeah I know but I am a new user and Since there is a limit for the new user, I dont know how much time will it take.
Got it. Hopefully the limit clears soon so you can make a proper post for it 🙌
Felt this hard. Built assuming users would navigate one way, they showed up doing something completely different. The original idea wasn't wrong, they just gave me a sharper version of it. The hardest part is not clinging to your original assumptions when behavior is telling you something different.
Yeah, I think that’s one of the most interesting parts of early-stage building honestly - reality usually adds a lot more nuance once real usage starts happening.
The gap is widest in client-facing work. 'Scope your project clearly' sounds obvious, but the moment you're on a call with a client who's pivoting mid-engagement, all the advice collapses into noise because no one told you what to actually say.
The advice that survives first contact is process-based: have a specific intake question for exposing unspoken constraints, have a specific script for when change requests arrive, have a specific message structure for overdue invoices. Not scripts in the sense of reading from a card - frameworks that let you stay professional when the situation wants you to get defensive.
What made my client work click was treating each difficult conversation type (scope creep, revision round 4, non-payment) as a skill to develop separately, not a general 'communication skill' to improve vaguely.
Interesting perspective. I think a lot of these situations become very contextual once real-world interactions and pressure enter the picture.
pressure does a lot of work that advice never accounts for. most frameworks assume you have 10 seconds to think. real conversations don't
This is very helpful
Appreciate it 🙌
The vocabulary shift is the part that takes longest to accept.
Your users will almost never use the same words you used when you described the problem to yourself. VIDI was probably built around 'contract review workflow' or 'document analysis speed'. The users who actually stay are probably describing moments: 'my client changed the scope after I sent the contract', 'got burned on a bad clause I missed', 'review took 4 hours and I billed 2'.
The same problem. Completely different vocabulary.
Product-market fit usually looks like the moment you rewrite your headline to use their words instead of yours - and the conversion rate changes that week. Everything before that is the cost of learning the gap.
How early did you start noticing the vocabulary mismatch between what you thought you were building and what your retaining users were describing?
Interesting perspective, but honestly a lot of the more specific positioning and user-language observations are probably something I’d rather keep internal for now.
The stage point is huge. A lot of advice is “correct” but only after you know whether the constraint is demand, activation, retention, or distribution. Early on I’d rather track the one behavior users repeat without being asked, then let that pull the roadmap.
Fair point. Early-stage dynamics can get very contextual very quickly, and a lot of signals only make sense once there’s enough real-world interaction happening.
I'd push back slightly - most advice assumes you already know your stage. figuring out which stage you're in is the first product problem. once you know, the advice clicks.
Yeah, I think a lot of it ends up being much more contextual and nonlinear in practice than most frameworks make it seem.
This really resonates.
The Lean Startup and Lean Customer Development influenced how I think about building, but I’m realizing the hard part is not just knowing the theory.
It’s seeing which assumptions break first when real users interact with the product.
The books give the mindset, but reality does the teaching.
Very true. I think the theory helps you start moving, but real-world interaction is usually what reshapes the actual understanding.
Totally agree. Early startups aren’t following a clear plan—they’re learning as they go.
We’ve seen the same: the idea starts it, but users shape what it becomes. That fast learning loop is everything.
Strong insight. Early-stage building is really a race to learn faster than your assumptions break.
We’ve seen the same: the vision starts the journey, but user behavior shapes the real product. That gap is where the opportunity lives.
What’s been the most surprising shift you’ve seen with VIDI so far?
Appreciate it 🙌 but some of the more specific shifts and internal observations are honestly something I’d rather keep private for now.
So true. Until you actually start building, every startup advice sounds good. Before building the startup, I head the lessons that make the product perfect, build it, more beautiful Ui/Ux need. But he real lesson I learned after building that, I need to validate the demand before building the product.
I need to sell before building, i need to get customers feedback to improve the product.
Yeah, I think different products and markets can require very different approaches early on. A lot of the learning only becomes clear once real-world interaction starts happening.
Absolutely
This is one of the deepest truths of early-stage building:
The vision gives you direction,
but reality earns the right to refine it.
A founder is not failing when the product shifts.
They are listening closely enough to let the market teach them what the idea could not reveal on its own.
Appreciate the perspective 🙌 reality definitely tends to reshape things much faster once real usage and feedback enter the picture.
i experienced the same things , dont know if my idea will work or does my idea really solve any problem and like that . i wasted a month just by thinking that and then made my self up and dive into building neglecting the thoughts of the outcomes . now its a way better cause i got a product and ready to deploy updates and a good community for building and for my product too . but need to work on some traction though
Yeah, I think a lot of this can look very different depending on the founder, the market, the product, and timing. Different people find signal and momentum in very different ways early on 🙌
I’m finding the same thing already with my iPhone game. Building the actual product feels weirdly deterministic compared to figuring out how real humans interact with it once it’s out in the world.
Even the marketing side has changed my assumptions massively. I thought polished promo content would matter most, but short scrappy gameplay clips seem to outperform almost everything because people respond more to moments than explanations.
Feels less like executing a fixed vision and more like steering a moving shopping trolley downhill while taking notes heh.
Yeah 😄 a lot of the strongest signals end up coming from real-world behavior instead of the original assumptions.
Great observation, Meirambek. The line "reality is usually more nuanced than the theory you start with" sums up most early-stage building perfectly.
One question for you: What's one specific user behavior from the last 11 weeks that completely caught you off guard? Like something they did that made you go, "Oh, that's not what I expected at all" – and how did you adjust?
Appreciate it 🙌 honestly some of the more specific behavioral patterns and adjustments are probably something I’d rather keep internal for now. Still learning from them in real time.
This resonates a lot as someone also in the early weeks of building.
The part about user behavior changing the product more than the original idea — I'm already seeing this and I haven't even launched properly yet. The assumptions I made about who would use it and how are already starting to look different from reality.
The advice that aged worst for me so far is "just ship and the right audience will find you." Turns out distribution has way more friction than I expected, especially when you're targeting a global niche from Southeast Asia. Geography shapes your early signal more than the product does.
Still in the thick of it but posts like this make the uncertainty feel less isolating. Appreciate you sharing the honest version.
Appreciate it 🙌 and yeah, I think early-stage dynamics can end up looking very different depending on the market, product, timing, and founder context.
Informative
Appreciate it 🙌
The advice with the biggest gap right now: 'create quality content, it'll compound over time.'
The theory is sound. The problem is AI overviews are cutting organic CTR by 30-60% on informational queries. Quality content that would have driven consistent traffic 2 years ago now gets zero clicks because the AI summarizes it at the top of the results.
The founders adjusting fastest are treating 'AI search inclusion' as a separate distribution channel - optimizing for being cited in ChatGPT/Perplexity answers, not just ranking in Google. That means structured definitions, clear answers above the fold, presence in forums and community threads that AI models index, and building citation trails.
Old advice: 'be the best answer on Google.'
New constraint: 'be the answer the AI gives - or be invisible to a growing chunk of your audience.'
Interesting perspective 🙌 honestly the distribution landscape feels like it’s changing extremely fast right now.
The hardest part is that early user behavior is usually noisy, not obvious. I like treating the first 10 to 20 users less like a validation sample and more like a debugging tool: what did they try first, where did they hesitate, what did they ignore, and what did they ask for unprompted?
Interesting perspective 🙌 I think early-stage behavior can sometimes become clearer faster than people expect too, depending on the market and product dynamics.
The advice that breaks down hardest when you actually start: 'track your metrics.'
Everyone nods. Then they build, and the metrics are in five different places - Stripe for revenue, a spreadsheet for leads, Notion for projects, a separate doc for client notes. Nothing talks to each other. You 'track metrics' but you can't answer 'what's my actual runway?' or 'which client segment is churning?' without 30 minutes of manual aggregation.
Advice like 'build systems before you scale' also sounds right until you realize no one tells you what the system should actually contain for a solo operator specifically. Enterprise frameworks are too heavy. Nothing is built for the founder who's doing sales, delivery, and ops all in the same day. That gap is real.
Interesting perspective 🙌 but a lot of the operational side is honestly something I’d rather keep internal for now.
My day job is pipeline forensics — predicting the remaining life of vintage water and sewer pipes from incomplete records. After 40 years across customer sales, engineering, and forensics, I've learned that Judgement is the order of the day: enough exposure to failure mechanisms and modes, enough material physics, enough scars to know which dot connects to which. In the after-hours I've been building with AI for the past year. AI helps, but it leans on historic records and standards, and interpretations of the "Why" regularly diverge.
Really interesting perspective honestly 🙌 appreciate you sharing that experience.
This is useful. I’m launching my first small developer product now and I’m realising that building the product is only half of the work - positioning and distribution are the harder part.
Did you get your first users mostly from communities, SEO, direct outreach, or existing audience?
Honestly a lot of that is pretty contextual and partially internal on my side, so I’d rather not go too deep into acquisition specifics publicly. Different markets and products can behave very differently early on.
I can relate this as developing an app from last 2 weeks.
The changes, logics everything slowly slowly changes what was planned.
Even AI starts making mistakes when complex or human made logic are used. But one thing after hours of development it gives immense pleasure after having a working model
Yeah, the reality of building usually changes a lot once the product actually starts evolving.
Yes, no one coaches you to your first successes and build upon that. That is so important and difficult to get.
Completely agree 🙌 early wins and momentum are underrated.
I think a lot of founders underestimate how much “finding the real problem” happens after you launch, not before. The original idea gets you moving, but user behavior usually tells you what actually matters. Some of the biggest shifts happen when you stop trying to force the original vision and start paying attention to what people naturally care about.
Yeah, I think a lot of important learning only starts once real usage enters the picture.
Jaa das stimmt es ist soo anstrengend sobald mal was in kopf hat und wenn man die Idee umsetzen will hab ich ein black out
Ja genau 😄 die Realität sieht am Ende oft ganz anders aus als die ursprüngliche Idee.
I really understand you. Speaking for myself, when I start a new project, I have one picture in my head. But when it actually starts working, I get a completely different reality.
Yeah exactly 🙌 reality usually ends up looking very different once users enter the picture.
What this really highlights is the difference between "optimization advice" (how to do something better) and "survival advice" (what to do when nothing is certain yet). Most canonical startup advice is optimization advice dressed up as universal truth.
The dangerous part: following optimization advice at survival stage often burns runway you need for actual exploration. I've found the best reframe is to treat every piece of advice as a hypothesis — test it in 2 weeks, then decide if it applies to your specific constraints.
I think the biggest problem is distribution and to get first 100 sales for any startup.
what's your take on this ? any suggestions or what are you currently doing for drive leads and sales.
Can’t lie that’s the biggest hiccup for any start up. Distribution, especially at the early stage can’t be just advice driven. Try different things and see what works that iterate on it.
That's true and still figuring out different approach
The worst advice I followed was "validate before you build." Spent 3 weeks on surveys and landing pages when I could've shipped an MVP in that time. The MVP taught me more in 48 hours than all the validation combined. The only advice that actually held up: talk to users every single day, and ship something every week. Everything else is context-dependent.
Honestly I think a lot of it depends on the founder, the market, timing, positioning, and how people discover the product early on. Different markets can behave completely differently.
Valid, it’s when the product hits the market that’s when you’ll actually feel if you built something good or not. Just feels painful when the market doesn’t react as expected
Yeah, determining on what you are building is the hardest part. In the early dev stage, especially with no budget to do public research, it's pretty hard to know whether the startup is going well or not. Unless there's something the product offers other big competitors do not, which makes it standout. Or it simply doesn't compete, just serves a particular underserving community.
I think a lot of it depends on the market and timing too honestly. Early-stage products can evolve in very different ways, and sometimes the strongest signal only appears after real-world usage starts happening.
Very true.
Most startup advice assumes clarity and stability. Early stage is mostly chaos + constant adjustment.
Seeing the same with Reloop too. We thought people would mainly use it for polished UGC ads, but many actually use it for testing hooks and shipping fast daily content
Users usually shape the real product more than the original idea.
Yeah, exactly 🙌 that shift between the original assumption and actual usage patterns is probably one of the most interesting parts of building early-stage products.
The advice-reality gap is mostly a signal problem. You read advice about 'focus on retention before acquisition' and think it applies. Then you realize your retention numbers are good - the real problem is that nobody who signs up is in your ICP. The advice was right, it just didn't apply to your specific failure mode. Founders who close this gap fastest aren't necessarily smarter about which advice to follow - they just have better operational visibility into what's actually happening in their funnel. When you can answer 'why did this user churn' in 30 seconds from your own data, you get a much faster feedback loop on whether the advice you're following is moving the needle. Most startup advice fails in practice not because it's wrong, but because you're applying general advice to a specific situation you can't actually see clearly.
The advice-reality gap is mostly a signal problem. You read advice about 'focus on retention before acquisition' and think it applies. Then you realize your retention numbers are fine - the real problem is nobody who signs up is in your ICP. The advice was right, it just didn't apply to your specific failure mode. Founders who close this gap fastest aren't necessarily smarter about which advice to follow - they just have better operational visibility into what's actually happening in their funnel. When you have a 'why did this user churn' query you can answer in 30 seconds, you get a much faster feedback loop on whether the advice you're following is actually moving the needle. Most startup advice fails in practice not because it's wrong, but because you're applying general patterns to a specific situation you can't see clearly. The antidote isn't better advice - it's better instrumentation.
Interesting angle, but I think at some point startup building becomes much more than instrumentation or funnel visibility alone. A lot of the important decisions early on are still highly contextual and hard to reduce to clean metrics.
That is true and I think that is also a part of the journey that once we start, then we get to live and experience. I’m not saying it’s easy. I’m saying it is a part of the startup founder.
Yeah, completely agree with that 🙌 a lot of it probably only becomes understandable once you actually go through it yourself in real time.
Most startup advice gets written from the post-Series-A version of the founder, where the noise has already been filtered out for them. At zero revenue and zero users, you're operating in pure noise — the same advice that's true at $1M ARR is wrong at $0 because the feedback loop hasn't started yet. The trick I've used: pick one advisor who is exactly two stages ahead of you, and ignore everyone else for 90 days. Beyond two stages, the operating context drifts too far to be useful.
Interesting perspective, but honestly I think a lot of startup building is much more contextual than fixed-stage advice frameworks. Different markets, founders, products, and timing dynamics can create very different realities early on.
Yeah and what collapses first for me is the "fixed-stage advice" framing itself. I've had ~$40 of agents running overnight loops for a week, and the only steps that survived contact with my actual situation were ones I'd rewritten three times after my market refused to behave like the advice assumed. Frameworks aren't wrong, they describe a median nobody actually is.
Yeah, I think reality usually ends up much messier and more contextual than most frameworks assume.
Most open-source alternatives feel decent for raw generation, but they still miss the polish and UI consistency Claude Design has. I think the real advantage is Anthropic’s prompting + design tuning pipeline, not just the model itself.
Interesting point honestly. I’ve been thinking a lot lately about how much product quality in AI apps comes from workflow/design layers around the model itself rather than raw model capability alone.
Funny enough, I touched on a somewhat similar “systems over features” shift in a recent post while talking about building VIDI:
https://www.indiehackers.com/post/from-rebuilding-doom-style-projects-at-10-to-building-vidi-at-21-e257ee0f7a
This resonates a lot.
I'm also in the early stage of building my first products, and the gap between “planned logic” and real user behavior is always bigger than expected.
What surprised me most is exactly what you mentioned — users don’t break the product, they redefine it.
Curious how you decide when to follow user behavior vs when to stick to your original direction? That balance feels like the hardest part early on.
Honestly I think a lot of that is just intuition, context, and experience over time. Probably hard to reduce it to a clean framework that applies universally.
Haha, the title made me laugh — so true.
Hahaha glad it resonated 😄
The "user behavior changes the product more than the original idea" point is the one that doesn't get taught because it can't be taught until you're in it. With ReleaseLog the shift was similar I thought the core value was the AI writing assistant. The signal that actually mattered was that founders wanted a public place to close the loop with users, not just publish faster. The publish speed was a feature. The trust loop was the product. The hardest version of what you're describing is when the original story you told yourself is still partially true it's not wrong, it's just incomplete. That's harder to let go of than being flat out wrong. What was the specific user behavior with VIDI that surprised you most?
Appreciate the perspective 🙌 and yeah, I think the “partially true but incomplete” point is very real. Probably can’t go too deep into the specific behaviors publicly, but some of the strongest learning definitely came from watching how usage evolved over time rather than from the original assumptions.
That makes sense, and watching usage evolve over time is probably the most honest form of product research anyway.
Eleven weeks in and you are already learning the most important thing: the plan is a hypothesis, the customer is the data. I have rarely seen a startup land exactly where the original deck said it would. Henson Group started as a mainframe integration shop and ended up as a Microsoft cloud reseller, same skill set, completely different product and market. At SocialPost.ai we thought agencies were the buyer; the early pull came from solo founders and small business owners. What separates the founders who make it is not stubbornness on the vision. It is speed of update on the evidence. Keep listening.
Appreciate this a lot Greg.
That’s honestly been one of the biggest lessons already - the market reshapes the original assumptions much faster than expected.
A lot of the strongest signals so far came from real-world usage rather than the original AI framing itself, which has been really interesting to watch evolve over time.
Really appreciate you sharing those examples from Henson Group and SocialPost.ai as well.
Seven years on the recruiter side before building. I thought that gave me a clear picture of what job seekers needed. Turned out I had a clear picture of what recruiters saw, which is a different thing.
What changed it was the beta. And the reason the beta worked was something I hadn't anticipated: every single tester was already an expert. Not of job searching in general, but of their own search. That's rare. If you're building an ecommerce tool, your beta users aren't all ecommerce specialists. But everyone who has ever looked for a job is a first-hand expert of that experience. The feedback was specific, personal, and almost impossible to dismiss.
The real signal that came back wasn't "one toolkit instead of five tabs." It was that users didn't know what they were doing wrong until it was shown to them. Gap analysis shifted from a secondary feature to the thing that made the product click. The product moved from "do this better" to "understand what's actually missing first."
The advice that aged worst: "launch fast and learn." True, but only once you can tell the difference between a real signal and someone being polite.
Interesting perspective 🙌 I think a lot of this probably depends heavily on the market, product type, and user behavior dynamics too. Different products surface useful signals in very different ways.
Yep. I’m seeing the same thing with a small iPhone nutrition logger. I thought the sell was “AI estimates macros from a photo,” but the sharper signal has been “logging should not feel like homework.” The feature details matter less than removing friction in the exact moment someone is eating. One useful filter has been: if the user has to plan ahead to use it, the habit probably dies.
Interesting insight honestly - feels like a lot of products eventually shift from “feature value” toward reducing friction around a specific behavior or moment.
This is so true.
There's a lot that I've had to learn quickly and under pressure in the last few months.
Honestly for me it’s been surprisingly fun more than stressful so far. A lot of learning, but I genuinely enjoy the process of figuring things out in real time.
This resonates. Building an SEO platform, original idea was full-funnel automation for agencies. Real usage looked nothing like that.
Most people who came in were small business owners and solo marketers running one audit, fixing what came back, then coming back two weeks later for another. Not workflows, just point-in-time checks. Restructured pricing and the product around that pattern.
The hardest part is letting go of the original story you sold yourself on. Took me too long.
Yeah, honestly that’s exactly the kind of shift I’m talking about.
The real challenge is usually recognizing when actual user behavior is telling a different story than the original thesis.
Yeah, unfortunately that's the deal. Working on your own product is infinite. The thesis keeps moving, users keep teaching you new things, and you just keep iterating. There's no finish line.
This resonates a lot. One thing we’ve noticed building AI systems is that real user behavior usually exposes assumptions much faster than internal testing ever does.
Especially early on, the challenge isn’t just building features — it’s figuring out which problems users actually care enough about to change their workflow for.
A lot of the biggest product shifts seem to come from observing unexpected usage patterns, not from the original roadmap itself.
Exactly.
A lot of the most important signals usually come from the things users do unexpectedly rather than the behaviors you originally planned around.
The specific place this breaks down in data work: founders set up their analytics stack based on assumptions about what to measure, and those assumptions reflect the product they thought they were building — not the one user behavior keeps telling them to build.
So you end up with dashboards full of metrics chosen in month 1, measuring an old version of the product. And maintaining those metrics has a real cost: it anchors your thinking to the original thesis even when the data is quietly signaling something completely different.
What I've seen work better at early stage is 'minimum viable metrics' — track only what you're actively making a decision with this week. If you're not changing behavior based on a metric, you don't need it yet. Add complexity to your data model as you understand your product, not in anticipation of what you might someday want to know.
The 'user behavior changes the product more than the original idea' point is exactly right. It implies your product/data feedback loop needs to run faster than most early teams have it set up. The bottleneck is usually not what you're building — it's how quickly you can see and interpret what users are actually doing with it.
For early-stage founders starting to instrument their product and query that behavioral data without a full BI stack, my free SQL diagnostic scripts are a solid lightweight starting point: https://growthwithshehroz.gumroad.com/l/psmqnx
Yeah, the “metrics anchoring you to an outdated thesis” point is actually really interesting.
Especially early on when the product is still evolving quickly - it’s easy to over-optimize around signals that no longer represent how users are actually interacting with the product anymore.
The “minimum viable metrics” idea makes a lot of sense in that context.
Exactly — and that 'minimum viable metrics' discipline is harder than it sounds because the natural instinct is to instrument everything upfront. But over-instrumented dashboards at early stage create a different problem: too many signals competing for attention, and the team ends up chasing noise. The feedback loop you're describing — where user behavior changes the product more than the original idea — only gets visible if you're watching the right few things closely, not 50 metrics loosely.
The gap between 'advice' and 'execution' is brutal. One pattern I've noticed: the friction isn't usually the product idea - it's the micro-tools that don't exist yet.
Example: I use voice dictation (Wispr Flow / Superwhisper) for most of my writing, and the biggest friction point isn't transcription quality - it's context-switching between different writing modes. Dictating a formal email sounds nothing like dictating technical docs.
Built custom AI prompts to handle this (different 'voice profiles' for each context) and it halved my cleanup time. Now I'm wondering if others have the same pain.
Curious: does anyone else use voice dictation for serious writing? Have you solved the context-switching problem, or is it something you just live with?
That’s actually a really interesting observation.
Feels like a lot of the friction in early workflows comes less from the core model capability itself and more from all the small context and interaction layers around it.
The “different writing modes” point makes a lot of sense too -people probably think very differently depending on whether they’re writing emails, technical docs, founder posts, notes, etc.
Haven’t checked in for a few weeks - a lot has changed already. Cool to see how fast everything is evolving.
Appreciate that - honestly the last few weeks have probably been the fastest learning period I’ve had so far while building this.
Very true — users usually shape the product more than the original idea does.
Yeah, honestly that’s probably been one of the biggest lessons for me so far while building this.
so
ok
If anyone’s curious what I’ve been building while going through this process:
https://vidicontract.tech/
This comment was deleted 3 months ago.