DEV Community: Matt Watson

Risks in Software Development: How to Match Your Caution to What’s Actually at Stake

Matt Watson — Fri, 26 Jun 2026 01:34:12 +0000

There’s one question every developer should ask before they change anything, and almost nobody is taught to ask it.

What’s the worst thing that happens if I’m wrong here?

Search “risks in software development” and you get the same article over and over. A tidy list of project categories. Budget risk, schedule risk, scope creep, technical risk, security risk. It reads like something a project manager keeps in a binder. None of it tells a developer how to do their actual job differently on a Tuesday afternoon when they’re about to push a change.

That checklist misses the risk that decides whether you’re any good. Every change you make carries a blast radius, the amount of damage it can do if it goes wrong. A senior engineer reads that blast radius before they start and lets it set how careful to be. A weaker one treats every line of code the same way, and that’s a problem in both directions. They move too slowly where nothing’s at stake, and they walk straight into the changes that look harmless but aren’t.

This is a guide to reading that blast radius. It’s written as much for our own engineers at Full Scale as it is for anyone else, because this judgment is the thing that separates a developer who moves the business forward from one who just takes tickets.

The real risk isn’t a checklist, it’s the blast radius of each change
Risk isn’t something you assess once at a project kickoff and file away. It’s a question you answer every time you open a pull request.

Think about the range of software a single company ships. Code that launches a rocket has to be perfect, because you can’t patch a spacecraft that’s already gone. Code that runs an internal dashboard three people glance at once a week can be wrong all day and nobody notices. It’s the same craft and the same language, but the stakes are nowhere close. If you build both the same way, you’re doing one of them wrong.

The skill is matching how carefully you work to how much damage a mistake can actually do.

Most developers never make that call consciously. They either bring the same heavy process to everything, which is slow, or they bring the same casual attitude to everything, which is dangerous. The good ones triage. They look at what they’re about to touch and ask how bad it gets if this breaks, and they spend their caution where it buys something.

Matt Watson: match how carefully you work to how much damage a mistake can do
A blast-radius ladder for the work in front of you
Here’s the mental model. Before you start, put the change on a ladder by its worst case. Two things set the rung: how much damage it can do, and how hard it is to undo. A bug you can roll back in thirty seconds is a different animal from one you can’t take back. The more damage and the less reversible, the more rigor it earns.

A simple way to judge reversibility is whether a change is a one-way door or a two-way door. A two-way door you can walk back easily: a small feature behind a flag, a config tweak, a deploy you can roll back in one click. A one-way door you can’t take back without enormous cost: the core architecture everything else gets built on, a database migration that rewrites millions of rows, a massive production cutover that swaps everything at once. Most day-to-day work is a two-way door, so it carries far less risk than it feels like, and you can move fast through it. Save your caution for the one-way doors, where getting it wrong has lasting consequences.

Catastrophic. Anything that touches money or sends messages to a lot of people. Billing code that charges a customer’s card twice. A job that fires emails or texts to your whole list. Anything that runs automatically at scale, so a single bug repeats itself thousands of times before a human even notices. Code like this can’t be wrong once. The clearest public example is the CrowdStrike outage in July 2024, where one faulty update crashed about 8.5 million Windows machines and grounded airlines, banks, and hospitals for roughly a day. One change, enormous reach, no easy undo. This rung earns the deepest testing, the most careful rollout, and a real review by someone who knows the system.

Serious but recoverable. This is where most of the real work lives, and it’s the hardest rung to judge. Customer-facing features, a data migration, an API change a few clients depend on. You can come back from a mistake here, but it costs you a bad day and some trust. The move is to find the one or two paths that actually matter and test those hard, not everything. On a checkout change, that’s the path that takes payment, not the one that updates the order-history label. On a data migration, it’s whether you can run it again safely if it dies halfway through. Test the paths that hurt if they break, get a second set of eyes on the tricky logic, and don’t get cavalier with the rest.

Low or trivial. The internal dashboard, the throwaway script, the new feature sitting behind a flag that only your own team can see. The worst case is you fix it in twenty minutes and nobody outside the building ever knew. Move fast. Heavy process here is pure waste, and waste is its own cost.

The same logic drives how much testing each piece deserves. We’ve made the whole argument for why testing depth is a leadership decision, not a QA checklist, and it comes down to this exact ladder. You don’t need test coverage on everything. You need it on the things that can hurt the business if they’re wrong, because that’s where tests buy you the confidence to move quickly. Security sits high on the ladder too, which is why we treat secure development as a set of practices baked into the work rather than a step at the end.

Blast-radius ladder: catastrophic, serious but recoverable, and low-risk changes
When software breaks, it is almost always about what changed
Here is something I want every engineer to internalize, because it changes how you should ship.

When something breaks, the cause is almost always whatever just changed.

When a system that worked yesterday falls over today, your first instinct shouldn’t be to go spelunking through the entire codebase. It should be to ask what changed since the last time it worked. That instinct only saves you if the answer is small. If you shipped one tight change, you can find the cause in minutes. If you shipped a giant release with forty things bundled together, you’re now hunting through forty suspects while production is down.

So the single most reliable way to lower risk is boring and unglamorous. Ship lots of small changes instead of a few big ones. A small change is easy to reason about, easy to review, and easy to reverse. A big release buries the cause of any problem in noise.

The rollout is the other half. You don’t have to turn a risky change on for everyone at the same moment. Feature flags let you decouple shipping the code from releasing the feature, so you can switch it on for a small group, watch what happens, and widen only when it holds.

Bugs are going to happen no matter how good you are, so the smart move is to find them with a small blast radius. Picture Tesla pushing a software update to every car on the road in a single night. If something’s wrong, the whole fleet has the same problem by morning. Now picture them rolling that update to a few thousand cars first, confirming everything behaves, and then expanding. Same update, wildly different risk. Get the change in front of a small set of real users first, especially when you already know it’s a heavy one.

Shipping to everyone at once versus rolling out to a small group first
The hidden risks: when “trivial” isn’t
The dangerous changes are the ones that look harmless. This is where developers who don’t understand production get hurt.

Adding a new index to a database table, or modifying an existing one, feels like nothing in your development environment. The table has a few thousand rows. The change runs instantly. You commit it and move on.

Then it goes to production, where that same table has 500 million rows. Now that “instant” index change can lock the table, run for hours, and bring the application to a crawl during the busiest part of the day. What was a one-line migration in dev needs a planned maintenance window and a careful rollout in production. The risk was never in the code. It was in the gap between what your laptop looks like and what production actually looks like.

Building a development team?
See how Full Scale can help you hire senior engineers in days, not months.

Book Discovery Call
You can’t judge a blast radius you can’t see. A developer who has never watched a system under real load, with real data volumes and real traffic, will keep mistaking high-risk changes for trivial ones. This is why understanding the production environment isn’t optional. The trivial-looking change that quietly breaks the thing next to it is the most common way good engineers cause bad outages.

8.5 million Windows machines crashed by one faulty update, July 2024
Most developers get risk exactly backwards
Now the uncomfortable part. Most developers don’t calibrate at all. They run scared on everything.

That fear is understandable. It isn’t their company. A mistake feels like it could cost them their reputation or their job, so they over-review, over-test, and ask permission for changes that carry no real risk. The whole team slows down to protect against downsides that were never going to be that bad.

I notice this because I don’t feel it. As a founder, I’m not afraid to make a change. If I break something, I’ll fix it, and I’m certainly not going to fire myself over it. An employee doesn’t get to feel that way as naturally, and that’s fine. The point of this guide isn’t to tell people to stop caring. It’s to help you see when to be cautious and when to ease off, so the caution lands where it counts.

There’s a catch to all of this, and it’s the fair objection to everything above. Telling people to move fast on low-risk work assumes they can tell low-risk from high-risk, and the index story just showed that they often can’t. So here’s the rule when you’re new to a system, new to production, or just not sure: treat the change as riskier than it looks and get a second read. Reading blast radius is a skill you earn by watching real systems break, not a license to skip review on day one. You ease off the caution as you learn where the bodies are buried, not before.

There’s a second way developers get this wrong, and it costs even more. They overengineer.

We needed a small internal tool recently, a quick and dirty MCP server, the kind of thing that should take a couple of days. Instead the developers wanted to architect it properly. They spent six weeks on it. When they finally delivered, it didn’t even work right, because in six weeks of building they never once let a real user try it. All that effort went into polishing something nobody had validated. The risk they should have been managing wasn’t “is this elegant enough.” It was “are we even building the right thing.”

The biggest risk is building the wrong thing
Every risk we’ve covered so far assumes the work is worth doing. The largest risk in software development is that it isn’t.

You can write perfect, well-tested, beautifully rolled-out code for a feature no customer wanted. All the rigor in the world doesn’t save you from building the wrong thing. At Stackify, we once spent $10,000 sponsoring a developer conference to launch a product, and we got zero new customers from it. The product wasn’t what people needed, and no amount of engineering quality was going to fix that.

We learned the same lesson a quieter way too. We assumed that more usage of our product meant more value, so we optimized to get people logging in more. Then we actually listened, and customers told us the opposite. “I just need to know why production is broken.” They didn’t want to spend time in our app. They wanted answers and to get back to work. The most valuable thing we could build was the thing that got them out of the product faster.

This is why getting real feedback early beats almost any other risk control. It’s also the heart of asking why before you build, a theme I come back to constantly in Product Driven. Shipping the wrong thing efficiently is still shipping the wrong thing.

Why reading risk is now the developer’s job, not the manager’s
For a long time the industry treated developers as order takers. Requirements came down, you built exactly what the ticket said, and judgment was somebody else’s department. That model is finished.

Now that AI generates so much of the code we ship, the bottleneck is no longer typing. It’s judgment. Developers have to understand the business problem, weigh the risk of different solutions, and go solve it without waiting for permission at every step. The 2025 DORA report put it well: AI amplifies what’s already there. Strong teams get faster and better with it, and weak teams just ship their problems quicker. The tool doesn’t supply the judgment. You do.

This is the real difference between a developer who multiplies a team’s output and one who drains it, and it isn’t raw speed or lines of code. It’s the ability to read risk and move accordingly, to go fast where it’s safe and slow down where it isn’t. The developer who treats every change like it might launch a rocket is the same drag on the team as the one who treats a billing change like a throwaway script. The one who reads each change correctly is worth far more than their salary.

That judgment is also exactly what you’re paying for when you hire a senior engineer, and exactly what you’re not getting when you chase the cheapest possible developer. We call that mistake cheapshoring, and risk judgment is one of the first things it costs you. A cheap body can write code. Reading the blast radius of a change, in your system, against your business, is the part that takes real experience.

How to actually calibrate: a software development risk management checklist
Risk management in software development doesn’t have to be heavy. Most of it is a handful of questions you run before you start, and a few habits that keep your blast radius small.

Before you make a change, ask:

What’s the worst case if this is wrong? Money, data, customer trust, or just a quick fix?
Is it reversible? Can I turn it off in seconds, or am I committed once it ships?
How many people does it touch if it fails?
Do I actually understand how this behaves in production, not just on my machine?
Then let the answers set your rigor:

High blast radius: deep testing on the risky paths, a real review, and a staged rollout behind a flag.
Medium: test the important paths, review the tricky parts, ship normally.
Low: move fast, skip the ceremony, fix forward if it breaks.
And keep two habits no matter what. Ship small so you always know what changed. Get the work in front of a real user as early as you can, because the worst risk is building something nobody needed.

AI Won’t Make You a 10x Developer

Matt Watson — Sat, 20 Jun 2026 00:40:15 +0000

A year ago I was the guy rolling his eyes at the AI demos.

I tried to use it back then to score sales leads, and I couldn’t get it to reliably do something as basic as flag every company with more than 25 employees. A plain “x > 25” was beyond it.

That wasn’t the 10x revolution everyone kept promising. Not yet.

Things have changed fast.

A year later, I just spent two weeks and about $4,000 in AI tokens rebuilding our entire website. I did it with what I’ve been calling our content engine: an AI agent I put together for the job, wired up with an MCP (Model Context Protocol) server, a Claude plugin, and a few other parts. It produces new content at a pace that still feels a little insane.

The tools genuinely got good.

But the pitch that they turn everyone into a 10x developer is still broken in a couple of ways, and once you see how, you spend your tooling budget very differently.

Writing code was never the bottleneck

Here’s the flaw under all the hype. How fast you can type code was never the thing slowing your team down.

The slow part is everything around the typing: knowing what to build, having the authority and ownership to go build it, and the skill and the time to do it well. AI is great at the typing, the easy and smaller part of the job. It does almost nothing for the rest of that list.

The numbers say the same thing. Atlassian’s 2025 survey of 3,500 developers and managers found that half of them lose ten or more hours a week to non-coding work: unclear requirements, meetings, waiting on a decision or an unblock. (atlassian.com) Most of the week was never spent writing code in the first place, so making the writing faster can only ever move a slice of it.

A senior developer at the research firm DX put the real gain plainly:

The easy tasks get a little easier, and a four-day task might take three.

Across 400 companies, DX saw AI usage jump about 65% while output rose only around 10%. The typing got faster, the shipping barely moved.

On hard work it can even reverse. METR ran a randomized trial on experienced developers in mature codebases. They predicted AI would make them 24% faster, and afterward they felt it had. They were actually 19% slower.

The tools feel fast while quietly costing you time.

Google’s DORA team put the cleanest frame on it: AI is an amplifier. Give it to your above-average developers and they go a little faster. Give it to the bad ones and it just turns them into AI slop machines. It magnifies what’s already there, it doesn’t manufacture it.

AI will write the code for you. It still can’t tell you what to build.

If everyone’s a 10x developer, nobody is

Here’s the second flaw, and it’s the one that should end the hype on its own.

If AI really did turn every developer into a 10x developer, then 10x would just be the new normal.

Everybody fast means nobody’s ahead.

The label only means something because it describes a gap between one person and the rest. A tool everyone has doesn’t create a gap. It lifts the baseline and leaves the spread exactly where it was.

Even in the world where the vendors are right, the 10x developer is still whoever was going to be the 10x developer anyway.

I’ve always been a 10x developer

I’ll say the thing the myth-busters won’t. The 10x developer is real, and I’ve been one. I’ve founded and sold 3 SaaS companies because of it.

The reason why is simple: I know what needs to be done. I know how to do it. And I can just go do it.

That is what creates a 10x developer.

There’s no organizational friction in my way. I don’t have to answer to anyone, ask for permission, wait on a ticket, or schedule a meeting before I start.

Take the content engine. Nobody handed me that project. I saw we needed content faster, decided how to build it, and built it. That’s the unlock, and it has almost nothing to do with how fast I type. It’s knowing what to build plus the authority to go build it without anyone slowing me down.

That is also why 10x shows up in startups and founders far more than in big companies. It’s not that the people are better.

It’s that the friction is gone.

There’s a second thing, and it’s less comfortable to admit. I worked around the clock on that content engine for two weeks and let almost everything else on my plate slide, because I was so infatuated with building it that I couldn’t focus on anything else.

It also takes passion for the problem.

That obsession is the magic in the bottle for 10x developers. When a problem grabs me, I disappear into it. A lot of that is ADHD, and the hyperfocus that comes with it is as much an edge as it is a problem.

If you want the longer version of that ADHD story, I wrote it up here.

Why didn’t anyone on my team build it?

That question has nagged me since I finished the content engine. My team had the same tools I did. Any of them could have built something like it. Nobody did.

Part of the answer is uncomfortable, and it lands on me. If the people around me are waiting to be told what to do, it’s partly because somewhere along the way they were trained to wait. They got handed tickets instead of goals, and nobody made it safe to go build something nobody asked for.

That’s a leadership failure before it’s a talent one.

My job stopped being the person who builds the thing. It became the person who builds the conditions where someone else does, and that shift is harder than building it myself ever was.

So the leadership work is concrete: hand people real goals instead of tickets, give them the authority to chase those goals however they see fit, and make it safe to build something that isn’t on the roadmap. Then get out of the way.

The problem is that can also be a slower at the beginning. It takes time and a different work culture for that to grow.

But here is the real key: ownership is the lever AI will never be.

I’d be lying if I said better leadership fixes all of it.

The ones who turn into 10x developers are the ones a problem can grab the way it grabs me, and you can’t install that with a goal-setting framework or an AI license. Plenty of strong engineers treat the job as a job, do it well, and go home, and that’s completely fine. You just can’t count on them to go build the thing nobody asked for.

That’s the real gap with AI right now. The gains don’t come from the tool; they come from the thinking, strategy, and judgment it takes to aim the tool at the right problem, plus the drive to do it unprompted. AI will execute almost anything you can specify. It still can’t decide what’s worth building, and deciding what’s worth building is most of the job.

At Full Scale, we changed how we interview developers a long time ago to focus much more on how they think: problem solving and product thinking. That’s the real unlock, and it’s what you need if you want to unlock real gains from AI.

Finding a true 10x developer is still a lottery ticket. But it starts with building the right work culture around them. They will never exist in a company full of red tape and bureaucracy.

So stop buying 10x

If you’re an engineering leader deciding how much to spend on AI this year, spend it.

The speed on the routine work is real and it adds up. Just don’t buy it expecting the 10x the hype promised, and don’t let it distract you from the work that actually moves the needle.

The developers who get the most out of AI are the ones who were already good at the parts it can’t do. If you want a 10x team, hire those people and give them room to run.

AI is leverage on judgment and ownership you already have. It was never a substitute for it.

Why I Love Boring Tech Startups

Matt Watson — Fri, 28 Apr 2023 14:22:57 +0000

Everyone wants to create the next Facebook, Slack, Zoom, or other big brands. They want to appear on Techcrunch and be labeled the next big thing.

Here is the reality… for every one of those well-known startups, there are 100 or maybe 1000 other companies you have never heard of.

I founded and sold a company you have never heard of for $150 million. Very few people in Kansas City had even heard of us, and we had 300 employees while doing tens of millions in annual revenue.

We never raised any money. There is no PR about our fundraising. We were off the radar, quietly reshaping an entire industry.

The best startups are doing the same. They are flying under the radar doing critical boring stuff nobody has ever heard of.

What’s a boring startup?

I define boring startups as companies working on things that are not trendy or chasing any current hype cycles. They usually solve real-world problems, and you have never heard of them. They are helping with logistics, supply chain, enterprise, or vertical-specific software. They are building solutions that are mission-critical to their customers.

Boring software companies are not as flashy. They don’t get all the press. They don’t charge $20 a month for some cute marketing tool. They charge more money for an industry-specific or enterprise solution because they provide more value to their customers. The companies tend to be more profitable and require less capital.

A lot of boring software companies are vertical-specific. Unless you work in that vertical, you have never heard of them.

Vertical vs Cross Vertical Startups

One of the biggest challenges for startup founders is focusing on a niche. When you first start, you want to explore lots of potential customers. You aren’t sure which customers are the best fit for your solution. At some point, though, you have to decide if you will focus on a very specific niche or if your product is designed for all types of companies.

Trying to build a product that anyone can use is often a mistake. When everyone is your customer, nobody is your customer. Although, you can also focus based on geography, company sizes, and other criteria. The biggest decision is to focus on a specific vertical or all verticals.

A vertical is another way of saying a specific industry. My first company, VinSolutions, was a CRM system for car dealerships. Today, they are the largest CRM provider in the industry, with something like 7,000 customers. Our product was full of features that were only relevant to car dealerships. Using our product for any other industry would not have made sense.

If you think of CRM, you probably think of solutions like Salesforce or Hubspot. They are examples of cross-vertical or horizontal solutions. They are more generic solutions designed for any industry.

Car dealers would have never used Salesforce or Hubspot. It wouldn’t have made any sense. Plus, the car dealer-specific ones had industry-specific integrations with the automotive manufacturers.

There are pros and cons to creating vertical vs. non-vertical startups. I would argue it is likely easier to do a vertical-specific solution. You can build something very specific for an industry. There is likely less competition, and you can create unique solutions only relevant to that industry.

The company I work at now does digital marketing. Doing that across all verticals sounds highly competitive. However, we only focus on home services like HVAC, electrical, and plumbing. We built unique solutions only for them. For that reason, we are the top vendor in the industry. We crush the cross-vertical solutions that try to compete.

The vertical focus will always beat cross-vertical. Vertical startups are more boring, which I prefer!

Creating glue

Another example of boring software companies aligns with the famous Brad Feld and one of his investment themes. He likes to invest in companies that are what refers to as “glue.” He even has a conference called GlueCon!

He defines glue as companies that provide the infrastructure and integrations that many other companies and technologies rely on.

Examples of glue companies are Amazon Web Services, Twilio, Akamai, Salesforce, and DocuSign. Also, software for cloud hosting, Kubernetes, and other infrastructure software.

Once a company uses these companies, it is hard to get rid of them. They are key infrastructure for companies, and their “glue” help hold things together for companies.

Building for the enterprise

Another example of boring software is building enterprise-specific solutions. By enterprise, I am referring to selling to medium to large corporations. Especially the Fortune 500.

It is hard to sell to enterprise companies. The sales cycles are long, and vendor approval can be painful. However, they are always looking to optimize their operations and are willing to pay top dollar. They are especially concerned about security issues and will pay extra for companies that cater to their needs.

Everything about selling to large enterprises is also boring! Love it!

I recently interviewed a couple guests on my podcast, Startup Hustle, that are perfect examples.

Island
Have you heard of the company Island? Probably not. They built a web browser focused on solving security issues for larger enterprises. Essential things like viruses, spyware, email phishing attacks, VPNs, etc. They have raised hundreds of millions of dollars and, I presume, are worth multiple billions.

Ironclad
How about Ironclad? Probably not. They built software to help companies create and manage all of their contracts. Large enterprises have lots of vendor contracts, sales contracts, etc. They have also raised hundreds of millions of dollars and are valued at over $3 billion.

Service based companies

When people think of startups, they usually think of SaaS companies. I have also been involved in two companies that were service-based. The digital marketing company that I currently work with is a service-based company. We are effectively a digital marketing agency that also provides a software solution.

About 5 years ago, I started a software development service company in the Philippines. I didn’t trust, or like how most outsourcing firms worked, so I started my own company to help my other company, a SaaS company. Full Scale now has 300 employees helping other companies build software. It’s a boring business, but we provide a mission-critical service to our customers!

Service companies are more labor intensive. They are harder to scale but also much easier to start. They require less funding and are much easier to make profitable.

Service companies are also pretty boring.

Boring doesn’t go out of fashion

Boring companies don’t go out of style. Island and Ironclad are perfect examples of that. Solving web browser security issues and dealing with endless contracts are problems that aren’t going away, especially for enterprise customers.

Now compare that to all the hundreds of AI companies that have popped up in the last 3 months. Some of them will make it, and some of them won’t. The hype of AI will fade away eventually.

Most boring companies provide critical infrastructure and vertical-specific solutions. Products that are deeply entrenched and hard to replace at most companies.

How eager would you be to change if someone told you they could provide you with a better accounting or phone system?

I bet your answer was NO WAY. Certain products are critical to a business and hard to change. Those are the best products to build. They are boring with a long lifetime of customer value.

It pays to be boring

Boring startups aren’t flashy or trendy. However, many of them are the plumbing that keeps most companies running daily. They are the mission-critical solutions that, if they go down, the whole business is out of business until it comes back online.

It is way easier to build a boring vertical-specific software company than to try to build the future Metaverse. Good luck, Zuck!

If you are considering starting your own software company, I highly recommend picking something boring. Service-based businesses are also a fantastic choice for a first-time entrepreneur because they typically require less capital.

It pays well to create boring technology that everyone needs.

Entry level developers can kill startups

Matt Watson — Wed, 22 Mar 2023 21:15:10 +0000

Nothing will kill a startup faster than entry level software developers.

Building a tech business is hard.

You have limited cash and time to build a product and get it to market.

Counting on entry level people to build the product is usually a formula for failure.

You will end up with endless delays and there is a good chance that it may have to be rewritten later.

When you don't have a big budget or don't know much about technology, it's easy to go with the cheapest option.

When you are betting your life savings on this company working, the cheapest option and entry level developers are not a good bet.

You need a good senior level developer to lead the development and do things the right way and faster.

You need someone you can trust, not someone who you hope will give their best college try.

Hiring only entry level or junior developers is a significant mistake for so many startups.

Make sure you have at least one senior software developer on your team.

Entry level people just don't know what they don't know.