DEV Community: Josh Cox

Failure Friday: Pebble Helped Create the Smartwatch Market—Then Disappeared

Josh Cox — Fri, 17 Jul 2026 15:37:00 +0000

Pebble is one of the most interesting startup failures because the company did many things right.

It built a product people genuinely liked.

It developed a loyal community.

It broke crowdfunding records.

It helped prove there was a real market for smartwatches before the Apple Watch even existed.

And it still failed.

The Rise of Pebble

Pebble began as a smartwatch company focused on creating a simple, practical wearable with long battery life and support for both Android and iPhone.

In 2012, the company launched a Kickstarter campaign seeking $100,000.

It raised more than $10 million.

That success showed there was strong demand for wearable technology, and Pebble quickly became one of the most recognizable names in the emerging smartwatch market.

Its watches were not trying to replace a smartphone completely. Instead, they focused on useful features like notifications, fitness tracking, apps, and customizable watch faces.

Pebble also built something many startups struggle to create: a passionate user community.

Then the Market Changed

Pebble’s early success attracted much larger competitors.

Samsung expanded its wearable lineup.

Google continued developing Android Wear.

Then Apple released the Apple Watch.

Pebble was no longer competing mainly against other startups. It was competing against some of the largest technology companies in the world.

Those companies had more money, stronger distribution, larger development teams, and existing ecosystems of phones, apps, services, and customers.

Pebble still had a respected product, but the competitive environment had changed.

Being First Was Not Enough

One of the biggest lessons from Pebble is that being early does not guarantee ownership of a market.

A startup can prove that demand exists and still lose when larger companies enter the same category.

Pebble helped validate the smartwatch market, but Apple and other major companies were better positioned to bring that technology to a much larger audience.

This is one of the risks of creating a new category.

The company that proves the idea works is not always the company that ultimately captures the market.

Crowdfunding Success Is Not the Same as a Sustainable Business

Pebble was one of the most successful crowdfunding stories of its time.

That generated significant attention, capital, and early demand.

However, crowdfunding campaigns can sometimes hide the larger challenge of building a sustainable hardware company.

Hardware requires:

Manufacturing
Inventory
Shipping
Customer support
Product development
Supply-chain management
Continuous investment in new models

A successful launch can create momentum, but the company must still maintain margins, manage operating costs, and fund future products.

Pebble reportedly faced financial pressure as competition increased and growth became more difficult.

In 2016, Fitbit acquired parts of Pebble’s technology, software, and intellectual property. Pebble stopped producing its watches.

The Lesson

Pebble proves that a startup can have:

A strong product
Loyal customers
Successful crowdfunding
Market validation
Brand recognition

And still fail.

The central lesson is that product quality alone is not enough.

Startups must also build a sustainable business, maintain access to capital, defend their market position, and prepare for larger competitors to enter once an opportunity becomes obvious.

Pebble helped create the modern smartwatch category.

But creating a category and controlling it are two very different things.

Why I Built Startup Graveyard

I’m building Startup Graveyard, a community-driven archive of failed startups and the lessons we can learn from them.

Most startup content focuses on winners.

I think the failures can teach us just as much—sometimes more.

You can explore more startup stories here:

https://www.startupgraveyard.co

Did you ever own a Pebble watch, or do you think the company could have survived with a different strategy?

Building My Home SOC: Why I'm Documenting the Journey Instead of Chasing Tutorials

Josh Cox — Wed, 15 Jul 2026 15:35:27 +0000

Cybersecurity has always been my passion, but I found myself jumping from tutorial to tutorial without ever feeling like I was learning the bigger picture. I think it all started when I was around 13, just messing around online with friends, pulling harmless pranks on each other and seeing who could break into whose account first. Fast forward to today—I'm 37 years old, about six months away from graduating with my B.S. in Computer Information Systems with a concentration in Cybersecurity, and I still get that same excitement every time I learn something new.

Over the years, I realized I was spending more time collecting tools than actually understanding them. I'd install a Linux distro, follow a tutorial, watch a few YouTube videos, then move on to the next exciting thing. I was learning bits and pieces, but never really building a solid foundation. A few days ago, that finally changed. What started as an extra Raspberry Pi sitting on my desk turned into an idea that I'm genuinely excited about, a Home Security Operations Center that I am going to build out over time.

This isn't a project about installing as many security tools as possible. It's about understanding why each one exists. Before I add anything to the lab, I want to be able to answer a few simple questions: What problem does it solve? How does it fit into the overall architecture? Could I explain it to someone else? If I can't answer those questions, then I'm not ready to install it yet.

Honestly, I have no idea where this project will end up. Right now it's just a Raspberry Pi running a handful of services, but I already know it's going to become something much bigger. My hope is that by documenting the entire journey—from the beginner mistakes to the more advanced projects—it'll not only help me look back on how far I've come, but maybe help someone else who's trying to break into cybersecurity too. If nothing else, it'll be a pretty cool journey.

I'll be posting updates as I go for anyone interested! and here is the link to my github repo if you would like to see what I have done so far!

Hightech89 / HomeSoc-Lab

A documented home cybersecurity lab focused on Linux, Docker, monitoring, logging, AI, and hands-on learning.

Home SOC Lab

A documented home cybersecurity lab focused on Linux, Docker, monitoring, logging, AI, and hands-on learning.

Mission

Home SOC Lab is my long-term engineering project to learn modern infrastructure, cybersecurity, and systems administration by building and operating my own Security Operations Center (SOC) at home.

This started out as a way to find something to do with an extra raspberrypi 4 I had laying around, and turned into something I think can be pretty big and fun to build.

Every service added to this lab must solve a real problem and contribute to my understanding of the systems I'm building.

Why This Exists

Like many people learning cybersecurity, I found myself constantly jumping between projects, tutorials, and new technologies.

This lab is my answer to that.

Instead of trying to learn everything at once, I'm building one system that grows over time.

The goal isn't to build the…

View on GitHub

Failure Friday: Jawbone and Why Innovation Alone Isn't Enough

Josh Cox — Fri, 10 Jul 2026 20:30:19 +0000

Some startup failures happen because nobody wants the product.

Jawbone is interesting because that wasn't the problem.

The company started by making Bluetooth headsets and speakers before expanding into wearable fitness trackers. It raised nearly $1 billion in funding and, at one point, was valued at more than $3 billion.

On paper, Jawbone looked like a future tech giant.

But over time, the company found itself competing against Fitbit, Apple, and other hardware manufacturers with deeper pockets and stronger ecosystems.

Being Early Isn't the Same as Winning

Jawbone helped popularize wearable technology, but being an early innovator didn't guarantee long-term success.

Hardware is difficult.

Margins are thin.

Products have to be manufactured, shipped, supported, and improved constantly.

Meanwhile, competitors are doing the same thing—often with more resources.

Funding Isn't a Competitive Advantage Forever

One thing I keep noticing while studying failed startups is that funding often gets mistaken for validation.

Raising money gives you opportunities.

It doesn't guarantee you'll execute better than everyone else.

Jawbone had talented people, a recognizable brand, and significant investment.

But execution, product quality, legal battles, and intense competition eventually caught up with the company.

The Lesson

Innovation gets attention.

Execution earns customers.

Adaptation keeps them.

A great idea can open the door, but consistently building a better product and responding to the market is what keeps a company alive.

That's one of the reasons I enjoy studying startup failures. They're often less about a single catastrophic mistake and more about understanding the decisions that slowly pushed a company off course.

Why I Built Startup Graveyard

I'm building Startup Graveyard, a web app that documents failed startups and the lessons founders can learn from them.

The goal isn't to criticize companies that failed.

It's to build a resource where founders, developers, and entrepreneurs can study what happened and hopefully avoid making the same mistakes.

https://www.startupgraveyard.co

What startup failure do you think deserves more attention than it gets?

Bringing My Son’s Anki Vector Back to Life with Raspberry Pi, WirePod, and Gemini AI

Josh Cox — Tue, 07 Jul 2026 01:43:15 +0000

A few years ago (2019), I bought my son an Anki Vector robot as a gift.

For anyone who never owned one, Vector was way ahead of its time. He was a small desktop robot with a surprising amount of personality. He could recognize faces, explore his environment, respond to voice commands, take pictures, answer questions, and genuinely felt different from most other smart devices.

He wasn't just another gadget sitting on a desk. He felt alive.

Then Anki went out of business.

Like many Vector owners, we were left wondering what would happen to this little robot we had brought into our home. Later, Digital Dream Labs acquired Vector and attempted to continue supporting the platform, but after more uncertainty around the service, it became clear that depending on someone else's cloud was always going to be a weakness.

The hardware still worked.

The personality was still there.

Vector just needed a new brain.

Years later, with the rise of open-source projects and modern AI models, I decided to see if I could bring him back.

The goal:

Could I take this older robot, replace the cloud services he depended on, and connect him to a modern large language model?

The answer ended up being yes.

Using a Raspberry Pi, WirePod, and Google's Gemma 4, I was able to bring Vector back online and give him capabilities that were not possible when he originally launched.

The Stack

For this project I used:

Anki Vector robot
Raspberry Pi running WirePod
Desktop PC running Ollama
Gemma 4 12B open model
Linux
SSH
Local networking

The final architecture looked something like this:

The Raspberry Pi essentially became Vector's replacement backend.

Instead of reaching out to external cloud services, Vector now communicates with WirePod. WirePod handles the request and routes conversations to a locally running AI model hosted on my own hardware.

The robot from 2018 is now powered by a modern LLM without relying on a company's cloud infrastructure.

Step 1: Taking Back Control of the Hardware

The first challenge was not installing AI.

It was getting control of the robot again.

Vector was originally designed around cloud connectivity. The hardware itself was still impressive, but many of the features depended on servers outside of the owner's control.

When those services became unreliable, it showed one of the biggest problems with connected devices:

The hardware can be perfectly fine, but the product can still stop working.

Using WirePod allowed me to replace that missing backend.

The process involved:

Setting up the Raspberry Pi
Installing WirePod
Connecting Vector
Configuring the replacement server
Getting voice commands routed correctly

After that, Vector was responding again.

But I wanted to go further.

Step 2: Giving Vector a Local AI Brain

Getting Vector back online solved one problem.

The next question was:

Could this little robot become something closer to the AI assistants we imagine today?

Originally, Vector's responses were limited by what he was programmed to understand. He had a lot of personality, but he was not built with today's large language models in mind.

I decided to connect him to Gemma 4 12B running locally through Ollama.

Now when I ask Vector something open-ended, the request travels from the robot, through WirePod, to my local AI server.

For example:

"Vector, explain how black holes work."

Instead of returning a predefined response, Gemma generates an answer and sends it back through Vector.

No subscription.

No external AI API.

Just my hardware running my AI model.

Challenges Along the Way

Like most projects, it definitely did not work perfectly the first time.

Some problems I ran into:

Bluetooth pairing issues
Getting Vector activated again
Raspberry Pi setup
SSH configuration
Networking between devices
Model configuration
Debugging why requests were not reaching the LLM
Balancing model size and response speed

One of the biggest lessons was realizing how many different pieces have to work together.

A simple voice question goes through the robot, networking, a replacement backend, an AI server, the model, and then all the way back.

When something fails, troubleshooting means understanding every layer.

Why This Project Matters

This started because I wanted to bring an old robot back to life.

But it turned into a much bigger lesson about AI, ownership, and the future of technology.

How many smart devices stop working because the hardware failed?

And how many stop working because the servers behind them disappeared?

Vector still had working motors, cameras, sensors, and personality. He just needed a new brain.

Open-source software and local AI made that possible.

What's Next?

Now that Vector is running with a modern AI backend, there are a lot of possibilities:

Persistent long-term memory
Custom personality tuning
More natural conversations
Home automation integration
Computer vision experiments
Agent-style workflows

This project started as restoring my son's old robot.

It ended with a small glimpse into where personal AI devices could be heading.

Sometimes old hardware just needs a new brain.

Failure Friday: Color and the Danger of Solving a Problem Nobody Has

Josh Cox — Fri, 19 Jun 2026 18:12:29 +0000

Most startup failures happen quietly.

Color did not.

Before it even launched, Color raised $41 million in funding and generated massive expectations throughout the tech world.

Investors believed it could become the next major social platform.

Instead, it became one of the most famous startup failures of its era.

What Was Color?

Color was a photo-sharing app launched in 2011.

The concept was that people in the same physical location would automatically share photos with one another.

Take a picture at a concert, sporting event, or gathering, and other nearby users could instantly see and contribute to the same shared experience.

On paper, it sounded innovative.

In practice, most people didn't understand why they needed it.

The Problem Wasn't the Technology

Color worked.

The app functioned as designed.

The team was talented.

The company had funding.

The problem was that users didn't immediately understand the value.

Many people downloaded the app, opened it, and asked a simple question:

"Why would I use this instead of the apps I already have?"

That's a dangerous question for any startup.

Funding Doesn't Create Product-Market Fit

One reason Color is so interesting to study is that it challenges a common assumption.

People often think that if a startup raises enough money, success will eventually follow.

Color proves otherwise.

Money can help you hire people.

Money can help you market.

Money can help you scale.

What money cannot do is force people to care about a product.

If customers don't see enough value, no amount of funding can fix that.

The Lesson

One of the biggest lessons from Color is that founders can become excited about an idea before proving that users actually want it.

A product can be technically impressive.

It can be innovative.

It can even attract investors.

But if customers don't immediately understand the problem being solved, adoption becomes incredibly difficult.

The best startups don't just build interesting technology.

They solve problems people already know they have.

Why I Study Startup Failures

I'm building Startup Graveyard, a web app that documents failed startups and the lessons founders can learn from them.

The goal isn't to make fun of failed companies.

The goal is to understand why they failed so builders can avoid making the same mistakes.

https://www.startupgraveyard.co

What startup do you think is the best example of a company that raised a lot of money before finding real product-market fit?

From a Gemma 4 Challenge Project to a Manufacturing Assistant App

Josh Cox — Sat, 06 Jun 2026 19:43:55 +0000

When I entered the Gemma 4 Developer Challenge, my goal was simple: build something useful, learn some new skills, and finish a project I could be proud of.

I didn't expect it to turn into something I might actually get to present at work.

For some background, I work in manufacturing. I've spent years operating equipment, troubleshooting problems, and watching experienced operators solve issues that newer employees often struggle with. A lot of that knowledge exists only through experience.

When I started thinking about ideas for the challenge, I kept coming back to a simple question:

What if there was an AI-powered assistant that could help operators troubleshoot issues, learn faster, and access information when they needed it?

That question became a prototype.

Over the past few weeks I've been building a manufacturing-focused troubleshooting assistant that allows users to describe an issue and receive structured guidance, troubleshooting suggestions, safety reminders, and recommended next steps.

The project started as a coding challenge entry, but something interesting happened along the way.

I mentioned the project to my operations manager. He thought it was interesting enough that he immediately reached out to our site's Learning & Development leader. Not long after, I received an invitation to meet and discuss the idea.

As someone trying to transition into tech while still working in manufacturing, that was a pretty surreal moment.

I have no expectations going into the meeting. It may simply be a conversation about ideas and possibilities. But regardless of what happens, this experience has already reinforced something important:

Sometimes the best project ideas come from problems you see every day.

Whether this prototype goes anywhere or not, it's been an incredible learning experience in AI integration, full stack development, user experience design, and building software around a real-world problem instead of an imaginary one.

I'll share an update after the meeting and let everyone know how it goes.

Have you ever built a side project that unexpectedly attracted attention from your employer or industry? I'd love to hear those stories

Failure Friday: MySpace and Why Being First Isn't Enough

Josh Cox — Fri, 05 Jun 2026 15:17:52 +0000

When people talk about startup success, they often focus on being first.

MySpace is a great example of why being first is not enough.

At its peak, MySpace was the largest social network in the world. It dominated social media, attracted millions of users, and became one of the most recognizable websites on the internet.

In 2005, News Corp acquired MySpace for $580 million.

Just six years later, it was sold for approximately $35 million.

So what happened?

The Market Didn't Disappear

One of the most interesting things about MySpace is that social networking itself didn't fail.

In fact, social media became one of the largest industries on the internet.

The demand was real.

The market continued growing.

The opportunity got bigger.

The problem was that competitors adapted faster.

User Experience Matters

While Facebook focused on simplicity, speed, and consistency, MySpace became increasingly cluttered.

Users could heavily customize their profiles, which sounded great in theory, but often resulted in pages filled with autoplay music, flashing graphics, and inconsistent layouts.

The platform became harder to use while competitors were becoming easier.

Over time, users voted with their feet.

Network Effects Are Powerful—Until They Aren't

People often think network effects create an unbeatable moat.

MySpace proves that isn't always true.

Network effects help when users are happy.

But if a competitor offers a noticeably better experience, even a massive user base can begin to migrate elsewhere.

Once that migration starts, network effects can work against the incumbent instead of protecting it.

The Lesson

Being first is an advantage.

It is not a guarantee.

Markets change.

Customer expectations change.

Competitors improve.

The companies that survive are usually the ones that keep improving even after they become market leaders.

MySpace didn't lose because social networking was a bad idea.

It lost because someone else executed the idea better.

Why I Study Startup Failures

I'm building Startup Graveyard, a web app that documents failed startups and the lessons founders can learn from them.

The goal isn't to make fun of companies that shut down.

The goal is to study the patterns behind failure so builders can avoid making the same mistakes.

https://www.startupgraveyard.co

What startup failure do you think offers the most valuable lesson?

Ops Assist: AI-Powered Manufacturing Troubleshooting with Gemma 4

Josh Cox — Mon, 25 May 2026 04:05:35 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

I built Ops Assist, an AI-powered manufacturing troubleshooting assistant designed for factory operators and industrial troubleshooting workflows.

The idea came from working in manufacturing environments where troubleshooting systems are often static, difficult to search, and unable to adapt to unusual combinations of symptoms or operator descriptions.

Traditional troubleshooting systems typically work like rigid decision trees:

Select department
Select machine
Select issue
Follow a predefined guide

That works for known/common failures, but real-world manufacturing issues are rarely that clean.

Operators usually describe problems in natural language:

“The conveyor only drifts after restarting.”

“The vacuum gripper randomly drops cartons during high-speed cycles.”

“The fault clears itself sometimes but comes back under load.”

I wanted to explore what happens when you combine AI reasoning with industrial troubleshooting workflows.

Ops Assist allows operators to enter:

machine symptoms
alarm or error codes
issue descriptions
severity levels
operational context

The app then uses Gemma 4 to generate:

likely causes
recommended diagnostic checks
safety reminders
escalation guidance
plain-English troubleshooting summaries

The project is currently an MVP prototype focused on validating AI-assisted troubleshooting workflows for manufacturing environments.

Screenshots

Demo Walkthrough:

The demo walks through:

entering a machine issue
AI-powered troubleshooting analysis
structured industrial troubleshooting output
safety and escalation guidance
real-time Gemma-powered response generation
Code

GitHub Repository:

Hightech89 / ops-assist

AI-powered troubleshooting assistant for factory operators built with Gemma 4.

This is a Next.js project bootstrapped with create-next-app.

Getting Started

First, run the development server:

npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev

Open http://localhost:3000 with your browser to see the result.

You can start editing the page by modifying app/page.tsx. The page auto-updates as you edit the file.

This project uses next/font to automatically optimize and load Geist, a new font family for Vercel.

Learn More

To learn more about Next.js, take a look at the following resources:

Next.js Documentation - learn about Next.js features and API.
Learn Next.js - an interactive Next.js tutorial.

You can check out the Next.js GitHub repository - your feedback and contributions are welcome!

Deploy on Vercel

The easiest way to deploy your Next.js app is to use the Vercel Platform from the creators of Next.js.

Check out our Next.js deployment documentation for more…

View on GitHub

Technical Overview
Stack
Next.js 16
TypeScript
Tailwind CSS
Gemini API
Gemma 4 26B A4B Instruct
App Router architecture
Architecture

The application uses a simple server-side AI architecture:

Frontend Form
↓
Next.js API Route
↓
Gemma 4 via Gemini API
↓
Structured JSON Response
↓
Industrial Troubleshooting Dashboard

The frontend collects operational issue details and sends them to a server-side API route.

The API route:

builds the troubleshooting prompt
injects safety constraints
requests structured JSON output
validates/parses the response
returns normalized troubleshooting data to the UI

The frontend then renders:

anomaly summaries
likely causes
recommended checks
escalation procedures
safety reminders
How I Used Gemma 4

Ops Assist uses the gemma-4-26b-a4b-it model through the Gemini API.

I chose the 26B A4B model because it offered a strong balance between:

reasoning capability
structured output quality
response speed
inference efficiency

Manufacturing troubleshooting is heavily reasoning-based. Operators rarely describe issues in perfectly structured ways, so the AI needs to interpret incomplete or inconsistent symptom descriptions and generate useful operational guidance from them.

Gemma 4 powers the core troubleshooting engine by:

interpreting operator-entered symptoms
identifying likely fault patterns
generating troubleshooting recommendations
providing safety reminders
recommending escalation paths

One challenge during development was balancing response quality with reliability.

Early versions of the troubleshooting prompt occasionally produced:

timeouts
malformed JSON
overly verbose outputs

To stabilize the MVP workflow, I:

reduced prompt complexity
constrained output structure
limited response lengths
implemented fallback handling
added JSON extraction/validation safeguards

This resulted in a much more reliable interactive troubleshooting experience.

I also found the use of an open model particularly interesting in the context of manufacturing environments.

Factories are often cautious about:

operational privacy
production data exposure
proprietary process information
external cloud dependencies

Open/local-capable models like Gemma create interesting possibilities for future on-premise industrial AI systems where operational data can remain inside the facility.

Example Use Cases

Ops Assist currently supports troubleshooting scenarios such as:

conveyor belt drift
intermittent jams
vacuum/gripper failures
sensor alignment faults
hydraulic pressure fluctuations
startup/shutdown inconsistencies
machine fault escalation guidance

Example operator input:

“Conveyor belt drifts sideways after stop/start cycles and causes jams. Only one lane is affected.”

Example Gemma output:

possible belt tension imbalance
startup torque inconsistencies
worn guide rails
roller alignment checks
escalation recommendation
lockout/tagout safety reminders
Future Improvements

Future versions of Ops Assist could expand into:

image-based troubleshooting
alarm screenshot analysis
multimodal diagnostics
maintenance history tracking
machine-specific troubleshooting knowledge
retrieval-augmented SOP/manual integration
local/on-premise AI deployment
Final Thoughts

This project was a really fun way to explore practical AI applications outside of the usual chatbot or productivity app space.

As someone working in manufacturing while transitioning deeper into tech, it was interesting building something inspired by real operational workflows and seeing how well Gemma 4 handled reasoning-heavy troubleshooting tasks.

Thanks for checking out Ops Assist.

# Failure Friday: What Quibi Teaches About Product-Market Fit

Josh Cox — Fri, 22 May 2026 18:40:43 +0000

Quibi is one of those startup failures that is interesting because, on paper, it had a lot going for it.

It had major funding.

It had experienced leadership.

It had celebrity-backed content.

It launched with a lot of attention.

And it still shut down less than a year after launch.

That is exactly why it is worth studying.

The idea was not completely ridiculous

Short-form video was already a proven behavior.

People were watching short videos on TikTok, YouTube, Instagram, Snapchat, and other platforms every day.

So the core idea of short mobile-first video was not the problem by itself.

The bigger issue was the way Quibi packaged that behavior.

It tried to turn short-form video into a paid standalone streaming service, while users were already getting short-form content for free from platforms they used every day.

That made the value proposition difficult.

A few lessons from Quibi

The first lesson is that funding does not guarantee product-market fit.

Raising a lot of money can help a company move faster, but it does not automatically mean customers want the product badly enough to pay for it.

The second lesson is that distribution matters.

Even if the content is good, people still need a strong reason to add another app, another subscription, and another habit into their lives.

The third lesson is that timing matters.

Quibi launched during a period when consumer behavior was shifting quickly, and its product did not seem to match how people actually wanted to consume short-form content.

Why I am studying failures like this

I am building Startup Graveyard as a web app for documenting failed startups and the lessons behind them.

The goal is not to make fun of companies that shut down.

The goal is to study the patterns behind failure:

Bad timing
Weak distribution
Scaling too early
No clear business model
Products people liked, but not enough to pay for

I think failure stories can be just as useful as success stories, sometimes more useful, because the patterns are often easier to see.

Startup Graveyard is live here:

https://www.startupgraveyard.co

I would also like to hear from other builders:

What failed startup do you think is worth studying?

What I'm Learning Building Startup Graveyard.

Josh Cox — Tue, 19 May 2026 13:07:50 +0000

One thing I’m noticing while building Startup Graveyard:

A failed startup is not always a bad idea.

Sometimes the timing was wrong.
Sometimes distribution failed.
Sometimes people liked the product, but not enough to pay for it.
Sometimes the market existed, but the business model did not.

That’s the part I want the site to explore more: the patterns behind failure, not just the names of companies that shut down.

Startup Graveyard is a web app where people can browse failed startups, read what happened, vote, comment, and submit their own examples.

The bigger idea is to eventually make the data useful beyond just reading individual stories. I’d like people to be able to study the patterns, compare failure reasons, look at trends, and maybe pull the data in a way that helps founders, builders, students, and researchers learn from it.

The technical side has been a big learning process too. I’ve been working with Next.js, Supabase, authentication, profiles, moderation, SEO, and deployment through Vercel.

It started as a simple project to learn about web dev, deployment, and to finally see one whole idea through.

Hopefully this project inspires people to learn from others mistakes!

https://www.startupgraveyard.co

I Built Startup Graveyard to Study Why Startups Fail

Josh Cox — Mon, 18 May 2026 01:46:37 +0000

I recently soft-launched a side project called Startup Graveyard.

The idea is simple: a place to browse failed startups, learn what went wrong, and pull lessons from their mistakes.

You can check it out here:
https://www.startupgraveyard.co

Why I built it

I have always been interested in startups, software, and the idea of building something from scratch. But the more I looked into successful companies, the more I realized that failed startups are just as useful to study.

A lot of failed startups had good ideas, talented teams, funding, users, or hype. But something still went wrong.

Sometimes it was poor timing.
Sometimes there was no real market need.
Sometimes the business model did not work.
Sometimes the product was interesting, but not useful enough for people to keep using.

I wanted to build a site that collects those stories in a simple, searchable way.

What the app does right now

Startup Graveyard currently lets users:

browse failed startups
search and filter by category
sort by newest, top, or A-Z
view startup detail pages
upvote startups
comment on startup pages
create an account
submit failed startups
manage their own submissions from a profile page

New submissions go into a pending review state before they appear publicly, so the site does not become a spam board.

Tech stack

I built it with:

Next.js
TypeScript
Tailwind CSS
Supabase for auth and database
Supabase RLS for security rules
Resend for production auth emails
Vercel for deployment

This project also helped me get more comfortable with real-world production concerns like:

authentication
email confirmation
row-level security
moderation
SEO metadata
sitemap and robots files
environment variables
deployment issues
preventing public email exposure
keeping user-submitted content controlled

What I learned

The biggest lesson from building this was that launching an app is not just about making the UI work.

There were a lot of things I had to tighten up before I felt comfortable sharing it publicly:

user emails should never show publicly
new submissions need moderation
users should not be able to self-approve their own posts
auth emails need production SMTP
database rules matter more than client-side checks
SEO needs to be handled before sharing links
a feature can work in development but still need production hardening

The app started as a simple directory, but it quickly became a good learning project for how real apps are built and protected.

What I want to add next

The next big improvement I want to make is a better failure pattern system.

Instead of only showing a basic cause of death, I want startups to be grouped by patterns like:

no market need
pricing failure
poor timing
distribution failure
funding or burn-rate issues
legal or regulatory problems
retention problems
founder conflict
competition
hardware/manufacturing issues

Long term, I would like the site to become more of a learning engine for founders and builders, not just a list of failed companies.

Feedback welcome

This is still a soft launch, so I would really appreciate feedback.

I’m especially looking for thoughts on:

the overall idea
design and usability
anything confusing in the flow
features that would make the site more useful
bugs or rough edges

Site:
https://www.startupgraveyard.co

Thanks for checking it out.

I’m Building a Startup Failure Archive With Next.js and Supabase

Josh Cox — Thu, 14 May 2026 18:16:05 +0000

I’m building a project called Startup Graveyard.

The idea is simple: a searchable collection of failed startups and post-mortems so builders can learn from what went wrong instead of only seeing success stories.

It’s built with Next.js, Supabase, and Vercel. So far I’ve added auth, startup submissions, comments, voting, profiles, and filtering.

I’m still polishing it, but I’m thinking about writing a dev.to post about the build process, what I learned, and some of the mistakes I ran into along the way.

Would this be something worth sharing?