2
1 Comment

6 Years of Incident Management Exp. and Zero Programming Background. Here's What Actually Happens When a Domain Expert Builds a SaaS With AI

I started building SimIncident on 28th May 2025.

Not because I had a brilliant business insight. Because I wanted to challenge myself in tough situations that aren't real. I wanted to feel the pressure of a major incident without it costing a customer their uptime. And I noticed nothing like it existed.

That was enough to start.

  1. What I was building
    SimIncident puts you in the incident manager role. Realistic scenarios from P2 to P0. A customer that loses patience if you go quiet. Resolving teams assigned based on the customer's actual tech stack. Decisions that compound in real time.

I had never written a line of production code in my life.

What AI actually did

The obvious answer is: AI wrote the code. That's true. But the interesting part is what happened when I had an idea and AI built on it.

I decided the simulation needed a drag and drop feature for building fix plans. That was mine. But in the conversation around it, AI sparked the idea of tying customer variables to the actions you take with them. The customer's patience, trust, and sentiment would respond to how well you managed them, not just whether the technical fix landed.

That changed the whole product.

What AI could not do was hold the vision. I returned to previous commits more than once because AI broke the UI without flagging it. I had to stay the person in the room who actually knew what the platform was supposed to feel like.

The hardest design decision

About four months in I had to decide whether the simulation should have a fixed correct answer or allow for different paths.

Real incident management is not clean. So I built a system where there is an ideal path, but you can still resolve the incident with a weaker outcome. The customer isn't always delighted. The score reflects it. But the incident closes. Just like in real life.

That tension between "there is a right way" and "real incidents are messy" took weeks to get right.

The moment I nearly quit

I locked V3 of the engine in September 2025 and looked at what was left. Nothing worked yet. Everything was scratch and design. I had thought I'd launch in late November or December 2025. I knew within weeks that was impossible. Then I locked V3 and nearly reset to never.

The thing that kept me going was a goal I'd set before I started. Finish the product no matter what. Even if it fails. See it through.

So I kept going.

The engine is now 99% ready. Beta is live at simincident.com as of this week. Launch on 31st July.

Where I am now, honestly

5 to 10 site visits per day. Beta testers not engaging yet. One tester made all the right decisions in the investigation flows and then quit from the pause screen. I don't know if that's a product problem or a life-got-in-the-way problem.

Marketing is hard. I knew coding would be hard and AI helped with that. I did not know that marketing would be harder.

What I do know: when I run a P1 myself, knowing exactly how the system works, I still feel something by minute 40. That means something.

One thing I'd say to someone starting the same way

Building is easier than it's ever been. Getting people to care is exactly as hard as it always was.

The domain expertise is the asset. Not the code. SimIncident is different from anything else in this space because it was designed by someone who spent six years running major incident bridges. That knowledge is in the product in ways that are hard to replicate.

If you have deep experience in a specific domain and you've noticed a gap, build the thing. Then figure out the rest.

simincident.com

Beta is live. If you work in incident management or SRE, honest feedback is what I need most right now. Reply here or sign up directly.

on June 17, 2026