I worked at a startup in the very early 2000s that was making online games in Java. Think applets with 2D sprite graphics.<p>They developed their own custom database, a shitty key value store that didn’t even have transactions because “Oracle doesn’t scale and it’s too expensive”. They couldn’t make reporting work so they copied the data hourly to Oracle anyway. (It turned out that Oracle does scale.)<p>They also invented their own RPC protocol, had their own threading library, used an obscure build system, an even more obscure SCM, etc…<p>Nothing was standard. It was all bespoke, <i>webscale</i>, and in-house.<p>When I started there as a junior they had me fix bugs in their code. Instead, I would simply delete thousands of lines of spaghetti and replace it with a call to a standard library. It was like spitting into a volcano to put out the fires of hell itself. There was no hope.<p>They burned $10M and made $250K revenue and collapsed.<p>Their competition used Oracle, ordinary tooling, and made tens of millions in profit.
Last startup I worked at spent a lot of time and money on creating a scalable cloud infrastructure. And thought every single thing we needed to do had to be written from scratch. And then rewritten to be nicer. But no market fit was found, or even an actual product at the end of the day.
The same is true for operations, if your business scales using humans you should avoid complicated tooling until you have product market fit. An old CEO curbed my enthusiasm by telling me “businesses are built on excel” and he was right.
I've spent a lot of time cleaning up the messes created by Experts like the article's author and I'm simply not convinced. It's easy to say "product market fit is King!!!" When you aren't the one working long nights and weekends reverse engineering code after a bug in pmf-hunting payment processing code made all purchases free for a day.<p>Stuff like ci lets you ship safely.
Part of the difficulty is navigating two sets of incentives. While yes, you can write fast and loose code that only a mother would love and do plenty of things much faster than whatever way is perfectly orthodox and correct. However, to be competitive in the job hunt, its expected people to have this portfolio of clean model code that follows all the best practices. The startup could fire you at any time, and you better have hoped you did your due diligence to spend part of your time on your own marketability instead of devoting it all to the startup, in this all too likely situation.
Out of curiosity, how long do people think it takes to setup e2e testing infra and ci/cd? Because for my startup I'm building as a solo founder, it took me 2 weeks and I really just can't imagine working any other way.
> Encore automates infrastructure for seamless development, from local to your cloud.<p>> Develop locally with instant infrastructure, preview PRs in dedicated environments, and skip tedious Terraform with automatic infrastructure setup in your cloud.<p>If you thought this sounded like a sales pitch for bad engineering practices, it’s because it is.<p>I find it very funny that a company hawking their mutant CI “solution” talks so much about pmf when what they’re selling is pretty undifferentiated
I agreed with a ton in this article, but just wanted to comment on this paragraph because I've seen similar notions be poorly interpreted:<p>> For engineers, this means taking shortcuts, making do with ready-made solutions, and focusing on speed of iteration over quality of iteration. You don’t get to spend time perfecting CI/CD pipelines or setting up the latest and greatest infrastructure-as-code versioning tool. You haven’t earned that privilege yet.<p>I agree, you shouldn't spend much time setting up the perfect CI/CD pipeline. That said, setting up a perfectly capable CI/CD pipeline in something like GitHub Actions took me literally less than a day, and maybe another day to work out some kinks.<p>I think it's important to focus on the author's primary point: The thing that is most critical is <i>optimizing your speed of iteration</i>. But too often I've seen this devolve into "we don't have time to build a simple deployment system!" or "we don't have time to write tests!" But the problem is that the lack of one-click deployment or any tests can become a <i>huge</i> drag on every single iteration in the future, and I've seen it absolutely sink companies.<p>Yes, things can definitely be over-engineered, and these days there are so many great, proven solutions for these common problems that it's a definite red flag if you build it yourself. But don't let that be an excuse for just generally shitty "we're a startup, we don't need to do XYZ" engineering practices.
Kind of disagree with this, which seems outdated given that it becomes easier and easier to implement best practices. Setting up CI/CD for a basic MVP is trivial, making it super easy to contribute makes iterations faster than just working on "product fit"
This is basically the same as the boring technology essay, no?<p><a href="https://mcfunley.com/choose-boring-technology" rel="nofollow noreferrer">https://mcfunley.com/choose-boring-technology</a>
I think the overall point for this is fine, but I'd argue that both Node.js and and MongoDB have basically crossed over into the "boring" realm at this point. I see Node.js used in lots of megacorporations, and I feel Mongo is more or less creeping its way into megacorps to for "stuff that needs to be fast and I don't care about ACID"; I think at this point I'd have to use one innovation token to talk some companies <i>out</i> of choosing Node.js.<p>That said, I do kind of hate this mentality; part of the reason that crap like Java 8 refuses to die is because companies always want to "established" tech, no matter how horrible of a fit it is.
I’m not a huge fan of this because it’s kind of painting all “original (technical) problems” with a broad brush, while also being a rewording of the typical YAGNI/establish PMF advice lines. I suspect the author is coming from the perspective of primarily working on “applications software” like consumer sites or solving some novel/poorly addressed business need with software.<p>A lot of these things aren’t binary yes/no decisions. They range from “don’t even do the thing at all” to “develop a custom solution completely in house”, sure, but with a huge spectrum of choices in between: buy off the shelf, get something basic but inflexible working, get something more advanced and flexible with more setup working, establish a process-to-be-automated that engineers perform manually.<p>Especially on the <easy setup, kinda shitty> to <hard setup, powerful/flexible> gradient you really need to consider your needs and options’ risk/reward. Some things like tests and CI have such quick payoff times you almost always want something that does a decent job of things. Moreover, when selling technical products half the time your competitive advantage is actually being able to efficiently iterate and improve on the product faster than everybody else because competitors are bogged down in tech debt and manual operations.
The article is a rehash of other sources and not particularly original, although it packages it in an easy to consume format.<p>It does have, though, an important insight that I haven't seen talked about much: when you do some upfront optimization (e.g. for scalability), even if you end up needing it, most often your solution ends up not being fit for purpose.<p>This is true for startups, but it also applies to software in general. By the time your product is scaling, it will probably have gone through quite a few changes, and it's likely that what you predicted would be scalability bottlenecks are off the mark. Not to mention how damn hard is to predict what issues a product you haven't yet built will face on the first place.
Am convinced there exists web tech that enables you to move fast enough without requiring a full rewrite once you confirm product market fit. Preferably with first class type safety throughout (rules out RoR/Django).<p>In ye olden days, we referred to this as “skill,” but I’m more sure we’re allowed to talk like that now :)