Dayzero
A product-testing exchange for people building software.
Hey Indie Hackers 👋
We’re building Dayzero — a product-testing exchange for builders.
We kept running into the same problem:
You build something for weeks, show it to someone, and hear:
“Looks great!”
But what did they actually understand? Where did they get stuck? Would they use it? Would they pay?
Getting genuinely useful feedback before launch is surprisingly hard.
So we built Dayzero.
The idea is simple:
You test someone else's product for 10 minutes → they test yours.
No paid testing panels. No subscriptions. Just builders giving builders useful feedback.
Testers follow a structured set of questions around:
First impression
Clarity
Bugs & rough edges
Usefulness
Willingness to pay
Biggest improvement
The goal is to help you answer one question before you spend another month building:
“Does this actually make sense to someone who isn't me?”
We're still very early and looking for builders to try it out.
If you're building something, how are you currently getting feedback before launch?
I expected people to say "there are too many options" or "the catalog isn't big enough." Almost nobody did.
What kept coming up instead was confidence. Finding tools is easy now. The hard part is trusting a recommendation enough to actually stop researching and start building. One builder pointed out the tools that survive aren't the ones with the most features, they're the ones with the fastest time to first useful output. Another asked how we'd handle the cases where there's no clean "right" answer, just tradeoffs you don't understand yet.
That's the gap we went after.
So Build doesn't just hand you a stack anymore. For every tool it picks, it now tells you why — what you're trading off (speed vs. flexibility, lower cost vs. more control), and where that choice will start to hurt later, whether that's a pricing cliff or a scaling bottleneck. The goal is not give you "this is the best tool," but "here's why this fits your situation, and here's the moment you'll want to revisit it."
To help get you building ASAP, it now generates a detailed starting prompt specific to your tooling stack, plus a short plan (stack.md) to keep in your project so your AI coding agent (Claude Code, Codex etc) stays consistent instead of drifting into something different every session.
Still early, still rough in places. But it feels much closer to the thing people were actually asking for; less directory, more "what should I do, and why."
Same question as last time: when you're choosing a stack, what would actually make you confident enough to commit? What's the thing you wish someone would just tell you straight?
I’m Charlie, building The Startup Index with my co-founder Noa.
We started this because finding the right software has become surprisingly difficult.
You Google a problem, land on a “Top 50 Tools for X” article, open ten tabs, read a dozen marketing pages—and still don’t know what actually fits your needs.
The discovery layer for software is broken.
So we built The Startup Index: a free tool that helps builders find the right tools faster.
It does two things:
Find: Describe your problem in plain English, like “I need to track bugs across Slack and email”, and get recommendations based on what you’re trying to achieve, not just keyword matches.
Build: Answer a few questions about your startup idea, and get an opinionated tech stack recommendation to help you ship faster. Designed especially for non-technical founders, designers, and first-time builders.
No paywalls. No gated results. Completely free.
We’re still early, and there are plenty of rough edges. We’re actively growing the catalog and improving recommendations every week.
I’d love your feedback:
What’s the hardest part about choosing tools for your startup stack today?
I’ll be sharing wins, mistakes, and learnings as we build in public.
— Charlie
-
1
researching tools when you should be building is brutal solo. I've lost more evenings to comparison rabbit holes than I'd like. the plain English query angle hits the actual pain - feature matrices never tell you what fits your setup.
-
1
For me the hardest part is the paradox of choice.
sometimes i’m genuinely trying to discover what exists, but sometimes “researching tools” becomes a socially acceptable way to procrastinate lol.
The annoying middle is when there are 10 tools that all look basically right, but with tiny tradeoffs i don’t fully understand yet. at that point i don’t need a bigger directory, i need an opinionated recommendation + why.
-
1
I agree - and this is a core part of the problem we are trying to solve. What information is important to a builder, so they can make the right decision, on the right information, at a specific growth stage. Understanding that and surfacing that to the user to make better decisions is the crux of it.
-
-
1
Very great tool and concept
-
1
thoughtful comment :)
-
1
THE BEST AND FASTEST RECOVERY HACKER EVER // WIZARD GEO COORDINATES RECOVERY HACKER
It is a privilege and honor to acknowledge WIZARD GEO COORDINATES RECOVERY HACKER for their time and dedication. I came across them at the right time, when I was scammed of my entire savings by a fake crypto investment site. They won’t allow me to withdraw my funds and request that I pay even more fees to be able to withdraw my money. I was devastated until I came across a post on my timeline about WIZARD GEO COORDINATES RECOVERY HACKER and what they are doing to help scam victims recover their funds. I thought it was impossible to do that but WIZARD GEO COORDINATES RECOVERY HACKER with their sophisticated cyber security and tools were able to help me recover my money. I’m truly grateful for their service and I recommend them to everyone who needs to recover their cryptocurrency funds and accounts. You can contact them via
WhatsApp ( +1 ( 318 ) 203-3657 )
With WIZARD GEO COORDINATES RECOVERY HACKER, you don’t have to face cryptocurrency theft alone. They are the leading recovery hacker with a track record of success, dedicated to helping you recover what’s rightfully yours. -
1
THE BEST AND FASTEST RECOVERY HACKER EVER // WIZARD GEO COORDINATES RECOVERY HACKER
It is a privilege and honor to acknowledge WIZARD GEO COORDINATES RECOVERY HACKER for their time and dedication. I came across them at the right time, when I was scammed of my entire savings by a fake crypto investment site. They won’t allow me to withdraw my funds and request that I pay even more fees to be able to withdraw my money. I was devastated until I came across a post on my timeline about WIZARD GEO COORDINATES RECOVERY HACKER and what they are doing to help scam victims recover their funds. I thought it was impossible to do that but WIZARD GEO COORDINATES RECOVERY HACKER with their sophisticated cyber security and tools were able to help me recover my money. I’m truly grateful for their service and I recommend them to everyone who needs to recover their cryptocurrency funds and accounts. You can contact them via
WhatsApp ( +1 ( 318 ) 203-3657 )
With WIZARD GEO COORDINATES RECOVERY HACKER, you don’t have to face cryptocurrency theft alone. They are the leading recovery hacker with a track record of success, dedicated to helping you recover what’s rightfully yours.
-
1
This resonates a lot — I just went through a version of this myself trying to figure out where to register ExitSign for visibility (G2, directories, etc.) and it really is overwhelming how much of "tool discovery" is just marketing copy dressed up as objectivity.
To answer your question: for me the hardest part isn't finding options, it's trusting any of them enough to actually commit. Most "best tools for X" content is either sponsored or written by someone who's never actually run the tool at scale, so I end up just asking other builders directly instead of searching.
The "Build" feature is the more interesting one to me honestly — recommending a stack based on the actual problem rather than a generic checklist feels like the harder, more valuable problem to solve. Curious how you're handling cases where there's no clearly "right" answer and it's more of a tradeoff (e.g. speed vs. flexibility).
Following this — good luck with the early grind.
-
1
Really appreciate this comment.
The trust piece is exactly what we've been thinking about lately. Finding options is relatively easy now; the harder part is feeling confident enough in a recommendation to stop researching and start building.
A lot of that comes down to context. A solo founder validating an idea and a funded team optimizing for scale should probably make very different choices, even when they're solving the same problem.
What we're exploring is making those tradeoffs explicit. Instead of saying "Tool X is the best," we'd rather explain why you might choose it: faster to ship vs. more flexibility later, lower cost vs. more control, simplicity vs. scalability.
And I completely relate to asking other builders directly. Honestly, that's the benchmark we're trying to match. If someone would trust a recommendation from a founder who's been through the same problem, that's the level of confidence we want to help people get to.
-
-
1
"you Google a problem, open ten tabs, read marketing pages, still don't know what fits" — this is genuinely the most underrated friction point in early-stage building.
the hardest part for me hasn't been finding tools, it's been finding the right next step once I already have a validated idea. there's tons of content on "which tool should I use" but almost nothing on "what should I actually do this week, in what order."
curious if you've thought about extending Build beyond tech stack into broader execution sequencing — or is that intentionally out of scope?
-
1
That's a really interesting observation.
We started with tools because it felt like the narrowest version of the problem we could solve, but the "what should I do next?" question comes up surprisingly often in conversations with founders.
My intuition is that tool selection and execution sequencing are actually connected. The right stack often depends on what stage you're in and what you're trying to accomplish next.
I could definitely imagine a future where the output isn't just "use these tools," but "here's the order I'd tackle this in."
-
-
1
Decision fatigue is definitely real.
I often spend more time comparing tools than actually building. The challenge isn't finding options anymore, it's knowing which stack won't create problems later.
Interesting idea. How are you handling new tools that launch every week?
-
1
When you talk about "won't create problems later" is this usually due to cost, scalability or some other concerns?
So it's early days, but we have a pipeline that ingests PH, YC companies and we manually add a lot of the obvious category leaders (eg. Jira, Linear etc). Building this out further at the moment, but trying to find the balance on genuinely great new products and noise is tricky to get right. Especially for products early in their lifecycle which are great but have limited traction.
-
-
1
I keep it simple so the tools is never the issue, I have it standardized to a few. The issue has been distribution.
-
1
I like your thinking, I've built an app that turns your materials (notes, lectures, whatever it is) into flashcards and I'm planning to profit it.
It's just that I have to prove that it will really get traction and long-term users -
1
Time has been an issue. I built a website a while back that didn’t turn a profit for five or six years—maybe my approach was wrong. Now I’m picking up valuable lessons on Indie Hackers.
-
1
I like the direction, but I'd probably pay for insights before I'd pay for data. A database tells me what exists. An index should tell me what matters. The biggest opportunity might not be helping founders discover startups, but helping them discover patterns.
-
1
This is a great way of putting it.
A database answers "what exists." The more valuable question is often "what should I care about?"
That's actually very aligned with where we're heading. People rarely ask for more options - they ask for more confidence. The challenge today isn't finding software; it's making good decisions in an increasingly crowded market.
We're increasingly thinking about how to help founders understand not just what's available, but what has the highest likelihood of working for their situation. What's worked for similar companies, stages, constraints, and goals? What are the tradeoffs? Why would you choose one tool over another?
The catalog is important, but we see it as the foundation. The real value is helping people cut through the noise, understand quality, and make better decisions faster.
Really appreciate the perspective - it's very much in line with how we're thinking about the problem.
-
1
That's an interesting shift. The best discovery tools may end up looking less like search engines and more like decision engines.
-
-
-
1
One of the biggest problems nowadays is TIME
-
1
For me, the hardest part is knowing which tools are actually “enough” for an early version.
As a beginner builder, I often see many options that all look good, but it’s hard to know what is simple, reliable, and not too advanced for the stage I’m in. I don’t want to overbuild the stack before I even know if users care about the product.
I’m currently building a small SaaS-style beta, and the biggest challenge is choosing tools that help me move fast without creating security or deployment problems later.
A tool that recommends a stack based on the founder’s actual stage and experience level would be really useful.
-
1
That's exactly part of the problem we want to help with. From personal experience I think that it's quite tempting to fall into the trap of over-building for future scale that does not yet exist before you've validated demand. So having a stack that allows you to spin up an MVP quickly, but is also capable of transitioning as product complexity and user growth scales is where we want to try and support fellow builders.
-
-
1
hardest part is building and i think most people just suffer from i don't know syndrome in which they think they don't how to build things but they actually know.
btw i pushed something today as i think building is what makes you productive!
-
1
The hardest part isn't finding the tool, it's predicting whether your team will actually adopt it. I ran an MSP for almost 20 years and watched plenty of "best on paper" tools die in week three because they added one extra step to someone's day. The winner is usually the tool that fits the workflow people already have, not the one with the most features. If your Build engine can weight recommendations by switching cost and time to first value, not just feature fit, that's the part nobody else is doing well.
-
1
You're completely right! We've mostly been designing for greenfield builds, but weighting by switching cost and time-to-first-value rather than feature fit is a genuinely different lens, and you're right that almost nobody does it well. I've been burned by a few third-party integrations gone sideways, so I also know this pain and the cost (incl. in time and effort) it incurs to orgs.
Curious as I think about how to weight this - from your 20 years: was there an early tell that separated the tools that stuck from the ones that died in week three?-
1
Yes, and it showed up fast. The tools that stuck got used by someone other than the internal champion inside the first week. If the only person logging in was the one who pitched it in the meeting, it was already dead, I just didn't know it yet. So the tell was not usage volume, it was usage spread. The second tell: time to first real output. If a person couldn't get one useful result on day one without a kickoff call or a training session, adoption never recovered. Anything that needed someone to be taught before it delivered value was quietly losing to the thing people figured out on their own. If your Build engine can surface those two signals, spread and time-to-first-value, you're measuring what actually predicts survival.
-
-
-
1
Interesting idea.
One thing I've noticed while building my first B2B product is that choosing tools is often easier than choosing the workflow.
For example, while building Sleuth (a reconciliation investigation tool), I could quickly find databases, LLMs, vector stores, and deployment platforms.
The harder question was figuring out what finance teams actually do when they investigate a discrepancy and which parts of that workflow are worth automating.
Curious if you've seen users struggle more with selecting tools or validating the actual problem they're solving?
-
1
One of the biggest problems nowadays is TIME... Any tool that can save time on repetitive tasks is halfway to success, but only if it delivers value and something that truly works in a simple and user-friendly way. And YES, this tool seems to be VERY useful and helpful, provided the recommended tools are truly the best for solving the problem we have. Now, with the thousands of tools available, and when several tools effectively solve the same problem, I'm curious to know what will actually make one the best choice over another(s)??? CONGRATULATIONS and keep up the good work.
-
1
genuinely curious how you're sourcing the catalog data right now, manually researching and writing up each tool, scraping marketing pages, pulling from existing directories, or some mix. that answer matters a lot for trusting the recommendations, since the quality ceiling of this whole thing is bounded by how good and current that underlying data actually is
-
1
The "Build" tool is the more interesting half of this to me. Recommendation engines for discovery are common, but most founders, especially non-technical ones, don't actually know what questions to even ask about their own stack until they're three months in and rebuilding something that should've been a five minute API call.
One thing I've run into building my own product is that tool categories shift faster than directories update. A tool that was "just a Slack integration" six months ago is now doing AI routing and decision making on its own, and most comparison sites still describe it by its old feature set. Are you treating the catalog as something that needs constant re-evaluation as tools add capabilities, or is it closer to a one time classification per tool?
-
1
this connects back to the sourcing question too, if classification is manual and one-time, drift is basically guaranteed at scale, 150+ tools is already too many to manually recheck regularly. if there's any automated signal feeding updates, changelogs, release notes, even tool subreddits mentioning new features, that's the difference between a catalog that stays accurate and one that quietly goes stale the way the comparison sites you're describing already have
-
-
-
1
Okay
-
1
I think the bigger challenge isn't finding tools anymore.
It's knowing which problems are worth solving first.
Most founders don't fail because they picked the wrong tool.
They fail because they're trying to solve ten different problems at once.
The pattern I've noticed is:
Problem clarity → Tool choice → Execution.
Most people reverse the order.
They start with tools, then look for problems to use them on.
Curious:
Have you noticed certain startup problems appearing over and over again regardless of the tech stack people choose?
-
1
"The discovery layer for software is broken" — completely agree. The SEO blog post trap is real.
For the "Build" recommendation engine, how deep do the questions go? Are you looking strictly at the product type (SaaS, marketplace, etc.), or does it also factor in the founder's budget and target timeline?
-
1
At the moment, and it is very early days, it is focused on budget and scale. I think timeline is definitely something we should look to introduce here. The way we have thought about it today is through a lens of control vs abstraction. So you have people who are happy to abstract all complexity to a no code tool but give up control as the trade off, then the other extreme is someone who's an expert in AWS or GCP and has strong opinions about detailed technical nuances - we're aiming to build something for the people in between. Curious from your perspective which filters or inputs would be most useful for a stack (eg. time, cost etc)?
-
-
1
Interesting approach. I think the biggest problem today isn't finding tools.....it's evaluating them. Founders spend hours comparing features, pricing, and reviews, only to discover weeks later that the tool doesn't fit their workflow. The idea of recommending solutions based on the actual problem instead of product categories feels much closer to how people think.
I'm curious: how do you plan to handle situations where multiple tools solve the same problem equally well? Will recommendations be based purely on feature fit, or will factors like budget, team size, and technical experience also influence the results?
-
1
On mobile, while scrolling through the recommended stack, there were long stretches where the scrollbar kept moving but the visible content barely changed. I initially thought the page had frozen. It eventually continued normally, but the scrolling experience felt confusing.
-
1
Agree. If we think in this way: Ideas are valuable because they help to ease pain of someone else. But you wouldn't understand that pain until you execute and solve it for someone else first.
-
1
I like the focus on reducing decision fatigue. Founders already have enough choices to make. Sometimes the best tool isn't the most powerful one, it's the one that gets you shipping faster.
-
1
Software discovery is definitely broken. We've moved from 'useful tools' to 'SEO-optimized landing pages' that all look and sound identical.
As a 'Portfolio Founder' building native Mac tools, I see the struggle from both sides. It’s hard for builders to be found, and it’s hard for users to find things that actually work.
Focusing on 'plain English' search is the right move - it bridges the gap between a founder's problem and the technical solution without the marketing friction in between.
Curious about the backend of the Index - how are the startups actually listed? Are you manually curating them to ensure a 'quality gate,' or is there an automated way for builders to submit their tools for indexing?
-
1
I completely agree - "we've moved from useful tools to SEO-optimized landing pages that all look identical" is the whole issue in one sentence.
On the backend: it's a hybrid by design. Automated discovery pulls new tools from public sources (YC, Product Hunt, Show HN) and works out what each actually solves in plain English. But nothing auto-publishes, there's a quality gate, because the value collapses the second the index fills with noise.
Two things I really want to get to: letting builders claim and own their page so they're not at the mercy of whatever got scraped off a landing page, and surfacing genuinely great tools from small teams. Right now discovery rewards the biggest SEO budget, not the best product, and we would love to flip that. Still working on the exact mechanics but i think user reviews and inputs will help a lot.
Self-serve submission is the piece I'm building next. Given you're shipping native Mac tools, want me to ping you when it's live?
-
1
Please do. My main app (mirowl.com) is already live and out of the 'screenshot graveyard' phase, so I’d be happy to be a guinea pig for your submission flow or manual curation.
Surfacing 'best product over best SEO' is a mission I can get behind. Small teams building high-performance native tools often get buried by SaaS giants. A discovery layer that rewards actual utility over who has the better copywriter is exactly what the ecosystem needs.
Looking forward to that ping!
-
-
-
1
Hi, Not sure I understood the concept and benefits.
-
1
What I found interesting is that "finding the right tool" and "making the right decision" often get treated as the same problem.
Sometimes they are.
Sometimes the tool search is really standing in for uncertainty somewhere else.
That's where recommendation products can end up teaching you something unexpected about what users are actually trying to solve.
-
1
Yeah, that distinction has been one of the more useful things I've picked up building this. A lot of searches aren't really "which tool," they're "I'm not sure what I'm actually trying to do yet." That's basically why Build exists alongside Find. Find answers "what tool," Build is closer to the decision underneath it. And you're right that the queries themselves end up being the richest signal, they tell us what people are actually stuck on, which often isn't the thing they typed.
-
1
Interesting response.
A few thoughts came to mind reading it, but they're probably better suited for email than a comment thread.
Happy to continue there if useful.
-
-
Comment