DEV Community: Josh Cox

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?

Hey everyone, First time posting on dev.to and first time entering a coding challenge here, so I figured I’d introduce myself a bit. I currently work as a machine operator while finishing my degree in Computer Information Systems, and I’ve been trying to

Josh Cox — Fri, 08 May 2026 18:26:28 +0000