Priorities for launching a SaaS solo, with no budget

Great list, and #5 is the one I'd argue is most underrated by solo founders — you nailed it. Coming at it from the same SEO-in-the-AI-era angle: I'd add that "trust signals for every source at once" now includes being machine-readable, not just human-readable. Things like a clean llms.txt, structured data, and making sure your site isn't accidentally blocking AI crawlers (a lot of people are, often without realizing it) directly affect whether an AI assistant will cite or recommend you. That's a channel that barely existed two years ago.
The one I'd personally move up is #3 (talk to real people). For me it's not just validation — it's the cheapest way to find the edge cases competitors ignore, which is often where your actual differentiation lives. The thing nobody asked for is usually sitting right next to the thing everybody needs.
On #4, agree completely that one good distribution move beats one more feature. The trap I'm watching for is picking distribution channels that are already saturated. The newsletter mention working better than your launch tracks with that — it was a less-crowded, higher-trust channel.
Re #6 — "no new modules until customer 50" is a brutal but smart line to hold. Curious: when you do talk to those early users, are you finding they ask for new features, or for the existing one to work better? That distinction has saved me from building a lot.

Your "no new features until customer 50" rule is the one I'd defend hardest — I run a few small apps and every time I stalled it was because I built instead of talked to people. One thing I'd add under "measure": separate curiosity metrics from return metrics early. A launch spike tells you the pitch is interesting, not that the product is needed — the number I actually trust is whether someone comes back in week three without me nudging them. With no budget you can't buy attention twice, so retention is the only asset that compounds. I'd also nudge "trust signals" up the list: as a solo founder, the "who is this one person and why should I trust the thing" question kills more conversions than a missing feature does.

The biggest time-saver for me solo: don't rebuild the boring infra. My first month went into auth, RLS, payments, image handling, GDPR — and I realized it's the same plumbing under almost every SaaS. If I restarted, I'd get that scaffolding done in a day and spend the rest of my time/budget on the actual product instead.

I ended up packaging the infra I built into a Next.js + Supabase starter. Happy to send a free copy if it'd save you the same month — no strings, just after honest feedback.

I love the "slap your own hand every time you want to build a new feature" rule. As solo builders, it’s so easy to hide behind coding a new feature because marketing and talking to users feels uncomfortable. Feature-creep is the ultimate form of productive procrastination.

Your point about trust signals in the AI era is also spot on. With ChatGPT, Perplexity, and Google AI Overviews taking over search, these engines prioritize structured, verifiable sources with real authors and trust signals. If the AI can't verify who is behind the data, you won't get cited.

Holding the line on zero new features and focusing entirely on distribution is incredibly hard, but it's the only way to survive the first six months.

Solid list, Galyna! Rooting for your journey.

One I'd add for the AI era: regulatory blindspot mitigation. A bill can change your product's legality or cost structure before you hear about it. State privacy laws, EU AI Act, sector rules. Solo founders typically find out from panicked tweets after it's too late.

I've been building something for this: tracking the legislative pipeline for bills that affect small software businesses. Pre-orders live at billwatch-landing.vercel.app if that's a gap you feel.

The no new modules until customer 50 rule is the one I'd underline twice. Cold outreach taught me the same lesson — structure and timing matter more than volume. I built ReplyAI after noticing that most AI tools optimize for generating text, not for getting replies. The buying situation has to be clear before any channel works.

That 'slap your own hand' rule until customer #50 is brutal, but honestly the most critical boundary on this list. Most solo founders fail because they end up building a ghost town with perfect features.
​Since you asked what to move up or down: I’d actually argue Trust Signals belongs right at the top with the clear offer. First impressions are purely visual and psychological; a stranger decides in 5 seconds if a bootstrapped tool looks sketchy or legitimate. Your SEO perspective here is spot on—having a real face and story does more for early conversions than any fancy feature.
​One small thing I’d add for zero-budget builders: Reducing feedback friction. Don't just give early users a cold contact form. Put a direct link to your personal DM, or a micro-widget where they can talk to you instantly. If they feel like they are building it with you, they become your champions.
​Massive respect for shipping this as a non-technical founder in just 7 weeks. Curious, how did you pitch that first newsletter to get featured without a budget?
​Would love to stay connected and follow your journey. I’m tinkering with some product ideas myself, and this mindset is exactly what I needed to read today.

Customer discovery before building > everything else. Most solo founders
skip it and build the product they think people want, then spend months
wondering why no one's buying. Talk to 10 target customers first, take notes,
then decide what to build.

The ‘no new modules until customer 50’ rule is the line I’d pin above the desk. Building feels productive, but for a solo founder with no budget, conversations and distribution are usually the real product work.

That is genuine experience you've got. I do face those myself as I am starting out my journey as solo builder too.

You give me a second thought about adding new features. Right now I am working on a project, trying to get users, and thinking of add new features to attract users.
But listening to you, I would better focus on improving the distributions, which I am doing at very minimum right now.

Thanks for the advice.

really insightful thought

That's great advice! I just launched my product for free and am actively trying to increase users

The "everywhere = nowhere" point is the one I'd underline.

I'm pre-launch on mytubefeed (nightly AI digest of your favorite YouTube channels) and the distribution question is keeping me up more than any technical problem. Every channel feels urgent when you have zero users.

The approval vs pain signal distinction someone raised is the one I'm trying to internalize before I start driving traffic. "Oh, cool..." reactions are everywhere. People who actually feel the problem badly enough to change behavior are a different thing entirely.

Did you start it as a side hustle/project or were all in?

I agree with the point about distribution beating features. As an engineer, it's tempting to keep building because that's the comfortable part. Getting users and talking to them is usually much harder, but that's where the real validation comes from. Curious what distribution channel has worked best for you so far besides the newsletter mention?

The "no new modules until customer 50" rule is the one I'd underline twice. What makes it so hard isn't a lack of discipline, it's that building feels like progress while talking to users feels like exposure. You get a little dopamine hit from shipping and a gut-punch from a "meh." Reframing feature-building as the more comfortable form of procrastination is the only thing that's helped me hold that line.

The one I'd gently push back on is "be visible everywhere." For a solo founder with no budget, everywhere usually turns into thin everywhere. You said one newsletter mention beat the whole launch, that's the real signal. I'd move "find the one channel where your niche already gathers and go deep" above the broad-visibility point. Everywhere is something you earn after one channel is working, not a starting strategy.

And on trust signals, fully agree they're underrated, but I'd add the fastest one of all: replying to people in public. A founder who answers every comment reads as more real than any About page can.

Great timetable - thank you.
Six months - clock started. I'll report back then

Your number one is right but most people get it backwards. They pick a time horizon (six months) and divide their savings by it to feel safe. The more useful version is figuring out your actual monthly cost to keep going. Not just server bills but the personal expenses that don't stop while you're pre-revenue. Health insurance, quarterly tax estimates if you had any prior income, all the stuff that's easy to forget when you're focused on building.

Once you have that real number, you can make better decisions about when to take on contract work to extend runway versus when to stay heads-down on the product. I've seen founders burn through savings faster than expected because they never separated "business costs" from "life costs" in any real way.

The constraint you set on yourself with no new features until customer 50 is smart. The financial version of that discipline is knowing your actual weekly burn and checking it against reality every month, not just trusting the original estimate.

As a solo dev saas/tools, I can relate at every cited step cited. Recently i started one of my business with zero budget for promotion, it's an hard task but the hard work pay. Loved your post

Greetings!

Checked your product earlier and honestly it feels like something Reddit users would naturally talk about because the underlying problem already gets discussed there often.But right now there’s almost no visibility around your brand itself yet.Just wondering, are you mainly relying on SEO and ads currently?I think people on reddit would actually discuss this

Great tips! Overall very accurate and goes to show that most of the work is not building the product. Once the core problem is solved, it is everything around that which will determine success. Completely agree with the list!

Going through this exact phase right now. The priority that has paid off most for me: before touching the landing page or the launch, go talk to people who already pay a competitor for the problem you solve. They hand you the real pitch in their own words, and everything downstream converts better. With no budget, your edge is doing the unscalable stuff nobody with a budget bothers to do.

This is a masterclass for solo founders. 'Cost your MVP to the bare minimum' is the best advice on here. Thanks for sharing your experience!

No-budget solo launch: my priority order has been — (1) 10 conversations with people who have the pain today, (2) one channel where they already gather, (3) everything else later.

Reddit/community replies beat ads at $0 if your buyers are there — but the time sink is finding the right threads daily, not writing the reply.

What's the SaaS and who do you think the first 10 paying users look like?

This is a sharp list, and the fact that you ranked "survive six months" as #1 instead of a tactic tells me you've already absorbed the thing most first-time founders learn too late. Runway is the precondition for everything else working, because everything else works on a timeline of months.

What I'd move, based on pattern:

#3 (talk to real people) should arguably be #2, above building the offer. You can't write the ten-second clarity in step 2 until you've heard real people describe the problem in their words. The offer is downstream of the conversations. Right now they're separate items but they're the same loop — talk, hear the language, build the offer from their words, test, repeat.

What I'd add: a distinction inside #4. "Be visible everywhere" is the one piece of advice here I'd push on. Solo with no budget, everywhere = nowhere. The newsletter mention outperforming your launch is the signal — that's one channel that matched. Better to find the one or two channels where your specific buyer already gathers and dominate those than spread thin across six. Visibility everywhere is a funded-team strategy. Depth in one channel is the solo-founder version.

One thing genuinely missing: a kill criterion. You've got "don't build features until customer 50," which is great discipline. But what's the number that tells you this specific idea isn't working and it's time to stop, not push harder? Without it, "survive six months" can quietly become "spend six months on something the market already told you no." The discipline to not build features needs a twin: the discipline to know when persistence becomes denial.

What's the product, and which newsletter moved the needle? That channel detail is the most useful thing in your whole post.

Your "no new modules until customer 50" line is the most valuable thing here, and it's the one most founders break first. I bootstrapped my SaaS and the months I lost were always the ones spent building instead of selling. The one I'd move up: talk to real people belongs above niche and offer, not below it. You think you're choosing the niche, but the conversations choose it for you, and the founders who validate first usually end up building something different from what they planned. That's the point, not a detour.

this list is good and the priority order is mostly right, the one i'd move is #3, talk to real people, all the way up, above niche and product. you've got it third, behind deciding who it's for and building the one useful thing. but in my experience the "who it's for" decision is the single most expensive thing to get wrong, and you usually can't get it right by deciding, you get it right by talking. i spent months building a genuinely working product aimed at the wrong customer, the buyer i was selling to didn't feel the pain my product solved, the people downstream of them did. the code was fine. the niche call was the bug. and no amount of "build one useful thing" fixes a useful thing pointed at someone who doesn't lose sleep over the problem. so i'd flip it: talk to real people first, let that decide who it's for, then build the one thing. otherwise you risk doing #2 beautifully in service of the wrong answer.

the one i'd most defend keeping exactly where you put it is #6, no new features until customer 50. that's the discipline almost nobody holds and it's the one that compounds. shipping a feature feels like progress and asks nothing of you emotionally; getting a stranger to tell you where your product failed them is uncomfortable and is the actual work. the hand-slap rule is right.

the thing i'd add that isn't on the list: separate "approval signals" from "pain signals." upvotes, likes, nice comments, those are approval, and they feel like traction but predict almost nothing. the signal that actually correlates is someone who felt the problem engaging like they felt it, asking pointed questions, telling you exactly where the wall was, coming back. a wall of polite praise is worse than three irritated questions from someone with the problem. easy to optimize for the former because it feels better. the latter is the one that moves the product.

This really resonates. One thing I struggle with is: how do you actually find real users to test with in the early stages? Especially when you don’t have an audience yet.

Amazing insights. I 100% agree with your take on product focus—an idea only works if it solves a real, high-value question for a specific group of people. Building less and talking to users more is definitely the way to go. Best of luck with your SaaS!

The distribution point is the one most founders underweight at the start. Building something nobody can find is the same as not building it. Your point about one newsletter mention beating the launch itself is something more people need to hear.
The thing I would add between your distribution and trust signals points: your messaging has to be doing the filtering work before any of those channels can pay off. You can be visible everywhere but if the first sentence on your page does not make the right person think ‘this is exactly my problem’ then the

Great list, and the fact that you put "survive six months" at the top tells me you've actually thought about this and not just collected tips.

One thing I'd move up, or at least make louder inside your point 3: talk to people before you're proud of the product, not after. I'm building profit analytics for Shopify stores, and the most useful thing I did was lurk in communities where store owners complain about money. Not to pitch, just to listen to the exact words they use. Turns out most of them don't say "I need profit analytics." They say "I'm doing 5k in sales but I don't know if I'm actually making anything." Completely different language, and it changed how I describe the product.

The one I'd push back on slightly is point 6. Agreed on not building features, but I'd separate "don't build features" from "don't improve the one thing that makes people trust the number." For me the product is the trust, so polishing how the core result is shown isn't feature creep, it's the whole job. Everything else, yes, hands off until customer 50.

Curious about your point 4. Which newsletter mention was it, and did you reach out or did it happen on its own? That's the part I find hardest as a non-native English speaker doing this solo.

knowing what to build when you can't afford to get it wrong is harder than not having budget. I shipped 6 features in 3 months that didn't move signups before I found the 2 that did.

Great list. I'd move distribution and talking to real users even higher because early feedback and visibility can save months of building the wrong thing. I'd also add content and SEO as long-term assets. A few helpful articles, tutorials, or case studies can keep bringing targeted traffic when you have no advertising budget. Consistency and solving one painful problem exceptionally well usually beat building more features.

This is a helpful topic because solo founders with no budget usually do not fail from lack of ideas, but from trying to do too many things at once.

If I had to prioritize, I would put the first 2-3 weeks almost entirely on narrowing the promise and getting direct feedback from real users. A simple landing page, one clear use case, and 10 honest conversations can teach more than polishing features too early.

For distribution, I would probably pick one channel only at the start. SEO, Reddit, cold outreach, Product Hunt, and communities can all work, but doing all of them at once makes it hard to know what is actually moving the needle.

The hard part is staying small long enough. One use case, one audience, one acquisition channel, one clear metric. Then expand after there is a signal.

faydalı oldu teşekkür ederim

Your point 3 (talk to real people) hits different for B2B tools built around episodic pain.

Compliance and regulatory tracking is the clearest case. A small business owner doesn't think about monitoring wage law changes until a bill actually passes. They're not in pain every day. They're in pain when something happens.

If you validate during a quiet period, you get 'nice idea, yeah we'd probably use something like that.' Then silence when you launch. The signal felt real but the timing was wrong.

Step 3.5 for that type of product: map the trigger event before you map the daily job. Your validation window needs to overlap with their pain window.

Building BillWatch right now (tracks government bills for small businesses - billwatch-landing.vercel.app) and this is the exact distribution challenge. The 'what if a law changes that affects you' pitch doesn't convert the same way 'save 2 hours every day' does. You're selling insurance, not productivity.

This is one of the more honest founder posts I've read here.

Point 3 and Point 5 together are where most first-time builders quietly fail — and they're connected in a way that's easy to miss.

Talking to real people validates the problem. But trust signals validate you as the person worth trusting to solve it. Both have to work together before anyone commits to paying.

The distribution insight (Point 4) also holds up — but I'd add one layer: distribution without a clear customer journey is just traffic.

One newsletter mention worked for you because presumably the landing experience converted that curiosity into something. Most founders optimize for visibility and ignore what happens after the click. That's where the real leak is.

The 'no new features until customer 50' discipline is underrated. Most products don't fail from lack of features. They fail because nobody mapped the journey from first visit to first value clearly enough for a stranger to follow it alone.

What you're describing isn't just a launch strategy. It's operational discipline — and that's rarer than the idea itself.

This is one of the more honest founder posts I've read here.

Point 3 and Point 5 together are where most first-time builders quietly fail — and they're connected in a way that's easy to miss.

Talking to real people validates the problem. But trust signals validate you as the person worth trusting to solve it. Both have to work together before anyone commits to paying.
The distribution insight (Point 4) also holds up — but I'd add one layer: distribution without a clear customer journey is just traffic.

One newsletter mention worked for you because presumably the landing experience converted that curiosity into something. Most founders optimize for visibility and ignore what happens after the click. That's where the real leak is.

The 'no new features until customer 50' discipline is underrated. Most products don't fail from lack of features. They fail because nobody mapped the journey from first visit to first value clearly enough for a stranger to follow it alone.

What you're describing isn't just a launch strategy. It's operational discipline — and that's rarer than the idea itself.

yes, i highly agree to this framework.

Moreover I am trying to build an ai desktop assistance that knows you and your work so you never have to waste your time re-explaining yourself to any ai or do not have to waste time searching for things you had seen a couple of days back. So, I want to talk to founders and ai-native coworkers who works on desktop and understand more of their problems and frustration to get up to right solution for them. ANYONE OR FOUNDERS let's talk!!

Thanks for sharing this. I agree with most of the priorities, especially the focus on validation and talking to users early.

One thing I would add is that when we say "no budget," we often focus only on money. As solo founders, time is usually the scarcer resource.

I've seen developers spend months building features because the monetary cost is close to zero. But if those months could have been spent validating demand, the opportunity cost is actually very high.

For me, the biggest priority would be:

1. Validate the problem.
2. Find where potential customers already gather.
3. Build only enough to test whether they'll use or pay for the solution.

A product can survive a limited budget, but it's much harder to recover from spending six months solving a problem that nobody really has.

I'm curious: if you had to choose only one activity for the first 30 days, would it be customer interviews, content creation, or building the MVP?

which one of these six you personally got wrong first, since seven weeks in you've presumably already broken your own rule on at least one of them before correcting course. the list reads like hard-won lessons, the interesting story is usually which one you violated before you wrote it down as a rule

I’d add one trust-signal angle for solo SaaS: make reliability visible and consequential early.

We just launched Uptimo for indie SaaS founders on Stripe who already use Discord. It watches uptime, auto-posts incidents to Discord, and ties 99.9% uptime to a simple $2/mo SLA penalty mechanic so the status page has real stakes.

Site: dev-uptimo dot nanocorp dot app

That $2/mo number is intentionally small: low enough for a solo founder to offer without enterprise-contract overhead, but concrete enough that reliability feels measurable to customers.

I’d move “talk to real people” even higher.

I built CueBuddy (a voice-following teleprompter) as a solo founder, and one thing I learned quickly is that assumptions are expensive.

Some of the features I thought users would love barely got mentioned. Meanwhile, small things users repeatedly complained about ended up having a much bigger impact on retention.

Also, I’d add one more item:

Ship before you’re comfortable.

As a first-time founder, it’s easy to spend months polishing. Real feedback only starts after real users touch the product.

A rough product with users beats a perfect product with no users.

Great post. Thanks for sharing your experience.

For a solo SaaS, I would prioritize conversations over traffic at the beginning.

My current approach is to validate one very narrow pain point first, then only build around repeated signals from real users.

The hard part is not getting visitors. It is finding people who have the problem strongly enough to explain their workflow, share messy examples, and tell you what they already tried.

So my order would be:

1. find 20 people with the exact problem
2. write down the same patterns that keep repeating
3. offer a small manual version before automating too much
4. turn the clearest repeated pain into a simple public demo

Curious if others here have had better results with content first vs direct conversations first.

#5 (trust signals) is the one I'd defend hardest too — and I'd push it further: make the trust signal something a stranger can independently verify, not just a claim. We run a small hosting company, and the single highest-converting thing we did was publish our live uptime on a public status page. Instead of asking people to trust a number on the sales page, we point them at the record: "check it yourself." Costs nothing, and it quietly answers "who is this and can I trust them" for humans, Google and AI at the same time.

One thing I'd add to #3: don't let "talk to real people" quietly turn into "build whatever the loudest person asks for." The signal is the pattern across many conversations, not any single request — that's a different (and harder) discipline than just collecting feedback. Solid list.

Completely agree. We need to start focusing on the few core features that actually make the product worth having, not just the features that we THINK the user wants.

I’d move distribution from “be everywhere” to “make each channel land somewhere specific.”
For qualified traffic, create 2-3 acquisition pages per audience/problem so a newsletter visitor, community visitor, and referral all see their exact use case.
That makes it easier to convert visitors before you spend more time building features.
I built Clustra for this — personalized acquisition page clusters for 39€: https://clustra.nanocorp.app

Really solid list especially the “survive six months first” framing. That’s the one most people underestimate.
I’m a solo founder too and I’m building Aureus (AI Business Guardian) focused on the three things that used to eat me alive: real cash runway visibility, smart hiring support, and risk/compliance alerts.
Your point about talking to real people from day one is spot on. I’ve been doing exactly that posting in communities and asking founders what ops pain is currently killing them the most. The feedback has already changed what I’m prioritizing.
One thing I’d add (or move up slightly) from my experience: Make distribution a daily habit, not a launch event. Commenting genuinely in relevant threads, sharing small learnings, etc. has brought me more real conversations than the actual “launch” did.
What’s been your biggest surprise in these first seven weeks something you didn’t expect to matter as much?

Insightful post. I wish I had read it years ago.
The "Collect (measures, feedback), don't guess" philosophy could have saved me months...

"Don't build new features" until customer 50 is genuinely underrated advice that deserves to be #1 for most people. The tension is that talking to real people (your priority 3) almost always surfaces feature requests, and it's very easy to convince yourself that building one more thing is "customer development" when it's really just procrastinating on distribution. I'd personally add "pick one acquisition channel and go deep" somewhere in the top 3 — what channel has been moving the needle most for you in these first seven weeks?

amazing advice, thanks for sharing it in a concise manner.

Just went through this tonight. Listed on AppSumo, G2, Capterra, Hacker News, and Product Hunt — all free. The channels exist, you just have to grind through every form one by one.

I get what you're saying by one distribution beatures one more feature, but I personally won't phrase it like that, to me it is more like: A "good enough" product that customers can easily discover and buy will almost always outperform a technically superior product that remains hidden. Either way is completely true.

This list is genuinely good, and the honesty about "observations, not rules" is the right posture. The one thing I'd add — not move up or down, but insert — is a kill-criterion. Your #6 (resist feature-building until 50 customers) protects you from over-building the wrong thing, but it doesn't tell you when the OFFER itself is wrong vs. just early. Without a pre-committed "if I do X outreach and get fewer than Y conversations/signups by date Z, I change the offer, not the features" line, a solo founder with a burning idea will almost always read weak signal as "need more distribution" and grind on a niche that was never going to convert. Decide that threshold now, while you're not emotionally attached to the result.

Second, smaller: make #4 measurable. "Distribution everywhere" quietly becomes "effort everywhere, attribution nowhere." Tag each channel (a UTM or a /go/<source> redirect) so after two weeks you can cut the four channels that did nothing and double the one that worked — with no budget, your scarcest resource is your own hours, and untracked distribution spends them blind. What does your first-conversation count look like seven weeks in — enough signal yet to trust the niche?

"Be visible everywhere" + "talk to real people" are doing more work than they get credit for. I run a daily routine of just commenting genuinely on LinkedIn, IH, PH, a few times a day, no budget, no ads. It feels too small to matter most days, but it's the only thing that's been consistently bringing real conversations and a few warm leads. The trap is treating distribution as a one-time launch push instead of a boring daily habit.

My no-budget priority order would be: one painfully specific user/job, one proof page, then 20 direct conversations in places where that pain already appears. I learned this with Kinetic Override: saying 'Android automation' was too broad, but 'Android 15+ no-root tap/swipe/long-press loops, local profiles, no ads' made the buyer/context clearer. Before ads or polished content, I’d validate that narrow wording in real threads and calls.

Strong list. Two things I'd move up from a recent launch in a regulated-adjacent niche (finance):

Trust signals — I'd put this even higher than distribution for solo founders. Not just an About page, but showing your baseline: where data lives, what you don't collect, export/delete without a support ticket. In finance people bounce on vibes before they read features. That stuff also compounds for SEO/AI citations like you said.
One public "try before signup" path — for me that beat polished landing copy. Let strangers hit the core value in 30 seconds, then ask for an account only when they want to save. Cuts fake validation from friends who signed up to be nice.
What I'd move down slightly: infra polish before first real user conversations. I run K3s + Pulumi + event-sourced Postgres (probably overbuilt for v1), but the useful signal came from people comparing our numbers to their bank schedule, not from the stack being elegant.

Re: customer 50 before new modules — respect. Hardest rule in solo SaaS.

Distribution first, always. The temptation is to polish the product one more week, but the first 50 users teach you more than 6 months of solo building. Even imperfect, you want real people hitting real friction. Budget zero doesn't mean reach zero — it means you're trading time for distribution instead of money.

I think one thing I've observed is that technical founders in particular focus on a product/solution and not on a real "pain". If the buyer can't quantify the value of solving the pain, it's just another product.

That's a cool list and all, but how much did you validate that in just a few month?

"I've come to think one good distribution move beats one more feature."
This certainly rings true for me. I switched to focusing on flashy visual features that play well on social and I think it's paying off.

Reminds me of Tony Fadell... designing the box first.

Reading this, I found myself wondering which parts of the list are observations and which parts are conclusions.

Those can look identical early on.

Sometimes the hardest thing isn't learning a lesson.

It's deciding when the lesson has actually earned the right to become a rule.