Readit News logoReadit News
mikert89 commented on AI agents are starting to eat SaaS   martinalderson.com/posts/... · Posted by u/jnord
benzible · 13 hours ago
I'm CTO at a vertical SaaS company, paired with a product-focused CEO with deep domain expertise. The thesis doesn't match my experience.

For one thing, the threat model assumes customers can build their own tools. Our end users can't. Their current "system" is Excel. The big enterprises that employ them have thousands of devs, but two of them explicitly cloned our product and tried to poach their own users onto it. One gave up. The other's users tell us it's crap. We've lost zero paying subscribers to free internal alternatives.

I believe that agents are a multiplier on existing velocity, not an equalizer. We use agents heavily and ship faster than ever. We get a lot of feedback from users as to what the internal tech teams are shipping and based on this there's little evidence of any increase in velocity from them.

The bottleneck is still knowing what to build, not building. A lot of the value in our product is in decisions users don't even know we made for them. Domain expertise + tight feedback loop with users can't be replicated by an internal developer in an afternoon.

mikert89 · 8 hours ago
A year or two from now it will be trivial to copy your product
mikert89 commented on AI agents are starting to eat SaaS   martinalderson.com/posts/... · Posted by u/jnord
mikert89 · 19 hours ago
"It was always possible to clone software, but doing so was costly and time consuming, and the clone would need to be much cheaper, making any such venture financially non-viable.

With AI, that equation is now changing. I anticipate that within 5 years autonomous coding agents will be able to rapidly and cheaply clone almost any existing software, while also providing hosting, operations, and support, all for a small fraction of the cost.

This will inevitably destroy many existing businesses. In order to survive, businesses will require strong network effects (e.g. marketplaces) or extremely deep data/compute moats. There will also be many new opportunities created by the very low cost of software. What could you build if it were possible to create software 1000x faster and cheaper?"

Paul Bucheit

https://x.com/paultoo/status/1999245292294803914

mikert89 commented on AI agents are starting to eat SaaS   martinalderson.com/posts/... · Posted by u/jnord
andy_ppp · 20 hours ago
I’m currently working on an in house ERP and inventory system for a specific kind of business. With very few people you can now instead of paying loads of money for some off the shelf solution to your software needs get something completely bespoke to your business. I think AI enables the age of boutique software that works fantastically for businesses, agencies will need to dramatically reduce their price to compete with in house teams.

I’m pretty certain AI quadruples my output at least and facilitates fixing, improving and upgrading poor quality inherited software much better than in the past. Why pay for SaaS when you can build something “good enough” in a week or two? You also get exactly what you want rather than some £300k per year CRM that will double or treble in price and never quite be what you wanted.

mikert89 · 19 hours ago
Its not that people will build their own saas, its that competitors will pop up at a rapid pace
mikert89 commented on Why Twilio Segment moved from microservices back to a monolith   twilio.com/en-us/blog/dev... · Posted by u/birdculture
mikert89 · 2 days ago
"Microservices is the software industry’s most successful confidence scam. It convinces small teams that they are “thinking big” while systematically destroying their ability to move at all. It flatters ambition by weaponizing insecurity: if you’re not running a constellation of services, are you even a real company? Never mind that this architecture was invented to cope with organizational dysfunction at planetary scale. Now it’s being prescribed to teams that still share a Slack channel and a lunch table.

Small teams run on shared context. That is their superpower. Everyone can reason end-to-end. Everyone can change anything. Microservices vaporize that advantage on contact. They replace shared understanding with distributed ignorance. No one owns the whole anymore. Everyone owns a shard. The system becomes something that merely happens to the team, rather than something the team actively understands. This isn’t sophistication. It’s abdication.

Then comes the operational farce. Each service demands its own pipeline, secrets, alerts, metrics, dashboards, permissions, backups, and rituals of appeasement. You don’t “deploy” anymore—you synchronize a fleet. One bug now requires a multi-service autopsy. A feature release becomes a coordination exercise across artificial borders you invented for no reason. You didn’t simplify your system. You shattered it and called the debris “architecture.”

Microservices also lock incompetence in amber. You are forced to define APIs before you understand your own business. Guesses become contracts. Bad ideas become permanent dependencies. Every early mistake metastasizes through the network. In a monolith, wrong thinking is corrected with a refactor. In microservices, wrong thinking becomes infrastructure. You don’t just regret it—you host it, version it, and monitor it.

The claim that monoliths don’t scale is one of the dumbest lies in modern engineering folklore. What doesn’t scale is chaos. What doesn’t scale is process cosplay. What doesn’t scale is pretending you’re Netflix while shipping a glorified CRUD app. Monoliths scale just fine when teams have discipline, tests, and restraint. But restraint isn’t fashionable, and boring doesn’t make conference talks.

Microservices for small teams is not a technical mistake—it is a philosophical failure. It announces, loudly, that the team does not trust itself to understand its own system. It replaces accountability with protocol and momentum with middleware. You don’t get “future proofing.” You get permanent drag. And by the time you finally earn the scale that might justify this circus, your speed, your clarity, and your product instincts will already be gone."

-DHH

mikert89 commented on The AI-Education Death Spiral a.k.a. Let the Kids Cheat   anandsanwal.me/ai-educati... · Posted by u/LouisLazaris
mikert89 · 6 days ago
College prestige locks people into life dependent paths, and needs to go away
mikert89 commented on Americans no longer see four-year college degrees as worth the cost   nbcnews.com/politics/poli... · Posted by u/jnord
mikert89 · 16 days ago
Employers just hire experienced h1bs instead, they won’t leave after being trained, no reason to hire an American
mikert89 commented on How good engineers write bad code at big companies   seangoedecke.com/bad-code... · Posted by u/gfysfm
sethhochberg · 17 days ago
Its hard to have good enough requirements gathering and documentation and product design practices to let an engineer really wrap their head around a problem well enough to come up with and then consistently follow a thoughtful, long-term-maintainable design for a system during implementation.

And its even harder to make sure everyone who reviews or tests that code has a similar level of understanding about the problem the system is trying to solve to review code or test for fitness for purpose, and challenge/validate the design choices made.

And its perhaps hardest of all to have an org-wide planning or roadmap process that can be tolerant of that well-informed peer reviewer or tester actually pushing back in a meaningful way and "delaying" work.

Thats not to say that this level of shared understanding in a team isn't possible or isn't worth pursuing: but it IS a hard thing to do and a relatively small number of engineering organizations pull it off consistently. Some view it as an unacceptable level of overhead and don't even try. But most, in my experience, hope that enough of the right things happen on enough of the right projects to keep the whole mess afloat.

mikert89 · 17 days ago
Eh, its either that, or the wrong people are getting promoted. Technical skills != business process modelling
mikert89 commented on How good engineers write bad code at big companies   seangoedecke.com/bad-code... · Posted by u/gfysfm
jjmarr · 17 days ago
Because businesses, as a rule, value moving fast. Being first to market makes money and generally results in winning.

Oftentimes the circumstances are "we don't know the requirements", not because of shitty management, but because the problem is inherently hard to define.

The business conditions that do heavily penalize bad architectural decisions, like physical structural engineering, can suck to work in compared to SWE.

It takes a decade or more before you're trustworthy enough to architect a building and there's a million layers of approvals. Then it takes years before groundbreaking, and years more as the building increases in size.

Your whole life might be dominated by a single large project like Hudson Yards, which has been floating around as an idea since 1956. The most recent proposal started in 2006, broke ground in 2012, and another 6+ years to finish. Then when companies were about to move their offices there, COVID-19 happened and the leases fell through.

I'd rather the system that gives average SWEs regular opportunities to lead large projects from scratch and make mistakes.

mikert89 · 17 days ago
I think you are underestimating how many product problems at big companies are actually bad technical debt. They cant release new features or evolve the offering because the systems are too complicated to change. 1 year of quick development could stunt the whole org for the next five years.
mikert89 commented on How good engineers write bad code at big companies   seangoedecke.com/bad-code... · Posted by u/gfysfm
bad_haircut72 · 17 days ago
100% this. Stuff like database schemas gets comitted in the first sprint and never gets refactored, which completely locks you in to long term design decisions, then every subsequent PR will get held up for days in arguments around meaningless "code quality" arguments which ultimately affect nothing
mikert89 · 17 days ago
ive never actually seen someone get fired for making some deep architectural software mistake. its alway for moving too slow, or "low code quality". i think people that were promoted for building systems that turned out bad, should be demoted
mikert89 commented on How good engineers write bad code at big companies   seangoedecke.com/bad-code... · Posted by u/gfysfm
mikert89 · 17 days ago
what I see alot is that the syntax and overall code architecture is text book, but its the completely wrong approach that creates extremely complicated tech debt. All the code reviews will be on the syntax, and none on the big picture of the business problem, or whether the implementation is overcomplicated.

in the short run (1-2 years) there is no repercussion for this, but eventually making changes will be extremely risky and complicated. The individuals that built the software will lord over everyone else with their arcane knowledge of this big pile of junk

u/mikert89

KarmaCake day439December 28, 2022View Original