TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Your tech stack is not the product

256 pointsby brendanneeover 2 years ago

27 comments

ChrisMarshallNYover 2 years ago
It&#x27;s funny. I&#x27;m working, right now, on a modular SDK that is the &quot;heart&quot; of an iOS app that we&#x27;ve been developing for a couple of years. I&#x27;ve taken functionality that was distributed all over a 30-screen iOS app, and distilled it into a simple-to-use, platform-agnostic SDK. This gives us a &quot;kernel&quot; that drastically improves the flexibility, quality, performance, and aesthetics of the app.<p>It&#x27;s a thing of beauty.<p>And absolutely no one but me, cares.<p>That&#x27;s exactly what I want.<p>I&#x27;m a little bit butthurt that no one wants to gaze in adoration at my cool toy, but it&#x27;s not open-source (as if that would even matter, as I&#x27;ve discovered that no one actually ever seems to <i>look</i> at open-source code). The app will work much better, as a result of the work that I&#x27;ve been doing for the last couple of months.
评论 #34362367 未加载
评论 #34362902 未加载
评论 #34362396 未加载
评论 #34363404 未加载
评论 #34362138 未加载
评论 #34362988 未加载
评论 #34364058 未加载
评论 #34381572 未加载
评论 #34362922 未加载
评论 #34362719 未加载
评论 #34362898 未加载
PaybackTonyover 2 years ago
This is something I preach often, even at FAANG. Often engineers feel comfortable and in-the-zone when solving for a process. One saying I often delivery is: Engineers often think their job is to build things. That&#x27;s not the whole story, they build things for _people_.<p>Nobody cares what your code looks like. Nobody cares what your architecture looks like. As engineers we should worry about creating forgettable experiences (at least in enterprise). They care that it does the job well, with low load times and an easy to use UX. That&#x27;s it. If you did your job right they&#x27;ll forget that software helped them do their job or complete their task faster &#x2F; better because the experience was so seamless they spent the entire time focused on their own goal, and not how to navigate your software to get there. How you get there is irrelevant. Now it&#x27;s your job as an experienced and intelligent engineer to make quick, thoughtful decisions on how to get your product to where it needs to be so that your _customers_ can create more impact on their own business &#x2F; lives faster.
评论 #34361653 未加载
评论 #34361814 未加载
评论 #34361656 未加载
评论 #34361817 未加载
评论 #34362723 未加载
评论 #34362465 未加载
评论 #34365146 未加载
评论 #34361691 未加载
评论 #34361839 未加载
评论 #34362563 未加载
neilvover 2 years ago
&gt; <i>If we pick exotic technology, it’ll be harder to hire (and we won’t ship as much product).</i><p>If you need to do something that&#x27;s not just generic CRUD app&#x2F;site... picking an exotic technology <i>that high-powered programmers love</i>, might make it <i>easier</i> to hire.<p>Compare:<p>&quot;We&#x27;re building a gig economy app to clean gas station bathrooms, and we eat our own dogfood!&quot;<p>to:<p>&quot;We&#x27;re USING RUST to build something (not a crypto scam, honest), and WE WILL PAY YOU MONEY TO HACK RUST, and did we mention RUST!!!&quot;
评论 #34362041 未加载
评论 #34361996 未加载
评论 #34362458 未加载
评论 #34365799 未加载
评论 #34363840 未加载
bcrosby95over 2 years ago
&gt; Why is Joe’s closet computer a bad choice? Because it’s a single point of failure and we won’t be able to ship fast if it breaks, which it will.<p>It&#x27;s kinda a shame they reduced it to this. A single machine in a colo center is going to be far more reliable than single availability zone in AWS, which is all many people resort to. And maybe we&#x27;ve just gotten lucky, but in general our very simple 20 machine colo center setup has been more reliable than our single region AWS setup.<p>But yeah, if you literally put Joe&#x27;s computer in a closet it isn&#x27;t gonna be too reliable for all sorts of reasons <i>completely unrelated to</i> the reliability of modern computer hardware.
评论 #34361884 未加载
评论 #34361932 未加载
评论 #34361800 未加载
评论 #34363707 未加载
cudgyover 2 years ago
This is why myopic technical founders need a balanced partner to help recognize the blending of company mission and company implementation.<p>However, it is natural for a myopic technical person to want to leverage their existing skillset, as this knowledge represents to them the key value that they bring to the organization. Unfortunately, blind loyalty to technical stacks is not likely to be an advantage, long-term. The ability to balance the need to leverage existing skills and taking advantage of new skills is critical.
cratermoonover 2 years ago
I joined a somewhat troubled project a year after it&#x27;s initiation. One of the things I learned is that early on, while the stakeholders were looking for visible progress, the tech lead decided to give them a presentation on the state of the system. What the stakeholders were concerned about was that they had not seen even a kernel of a working system. The tech lead, I&#x27;m told, focused on the tech stack, the implementation details, the integration points with existing systems, and a whole bunch of things that had the stakeholders dozing off within a short time. I think the only reason project wasn&#x27;t cancelled there and then was because it was in a critical path for the business.<p>I 100% believe that the tech lead gave this presentation, because part of my onboarding, such as it was, went over pretty much all the technical details of how the system was built, but never did I really get a sense of what the goals were, what functionality was in place, or any overall understanding of what all the pieces were supposed to be doing. Yeah, ok, it&#x27;s great that you created a bunch of code using gRPC to communicate internally and connected up to bunch of REST backend services sending and receiving JSON, but so what? How did any of that address the functional needs of the stakeholders?
Barrin92over 2 years ago
Very good post. A few years ago there was an interesting post linked here on HN about Stackoverflow&#x27;s tech stack and I was surprised how simple it was. Basically a bunch of servers cache, load balancer, dotnet, sql. And in reality for most projects that is honestly just about what you need.
agentultraover 2 years ago
Put another way, startups are trying to find a way to exploit a market niche as fast as possible. They happen to use software to do it. They’re (usually) not in the business of engineering.<p>I say <i>usually</i> because some startups are building new computers, libraries, and software infrastructure and care a lot about things that SV-style startups don’t.<p>Which means: this isn’t universally true advice. If I’m buying a new computing system from you I’m certainly interested in your tech stack and it will be a key feature.<p>But if your business is getting people to buy more things they don’t need then yeah, use a batch script and some spreadsheets if that gets you to market faster.
ummonkover 2 years ago
I don’t disagree with the sentiment and point of the article.<p>That said, I’d argue that if as a startup you believe you’re probably going to quickly and easily achieve product market fit, it is perfectly rational to focus on laying the right technical foundations so you don’t end up saddled with tech debt down the road. Once the product has become complex, rewrites are incredibly hard. And there are multibillion dollar companies out there dealing with the consequences of a tech decision a founder made in the first month of development while being focused on finding product market fit.
评论 #34362623 未加载
blitz_skullover 2 years ago
Counter-point—If your stack isn&#x27;t ergonomic, you&#x27;re going to ship less product. Don&#x27;t spend all your time fretting about your stack, but definitely make it delightful to work with.
rektideover 2 years ago
This is true only because there is a huge wall between users &amp; devs. Indeed: that&#x27;s a safe bet for the foreseeable.<p>But over time, for some...<p>I strongly want to believe that malleable software will find a niche and grow it. Expert users are a sight to behold, even with the limited offerings we have about, be it IFTTT, Excel, apple&#x2F;windows automation tools, or what-have you. If a system can actively work to onboard, to layer it&#x27;s complexity, to make it&#x27;s flows observable &amp; hackable, there&#x27;s a good chance we could start emerging new kinds of power users, could start onboarding more people into software &amp; systems literacy, in a non-overwhelming &amp; fun way.<p>The web has a hackability like this, that is joyous: writing a small userscript to tweak or rework a site to your own pleasure can be phenomally easy &amp; fun, is a great way to get folls started with &amp; enjoying computing.<p>Again, the advice here is good. Most people are not trying to strike at the roots of human-computing interaction.<p>But some folks should be, knowingly, with intent to make open, transparent, hackable software. Soft software. And in these cases, the stack matters enormously, is the truthful reality behind the obfuscating veil of interface. Efforts like Naked Objects are about more honest systems, and when we invite the user in, invite them to our level, bestow real power upon them, these invisible opinions implicit in our stack become much more the shape of the thing.
nunezover 2 years ago
this post reminds me of the dude that wrote plentyoffish, the worst&#x27;s worst looking dating site, in like ASP.NET or something and was able to sell it for hundreds of millions because basically everyone used it<p>or craigslist<p>i like new tech quite a lot but so much of this stuff are solutions looking for problems
habitueover 2 years ago
&gt; customers are not paying for, nor give a shit about, these things.<p>Yes, but they do give a shit if:<p>- your product is slow, so they assume it&#x27;s crap and leave your site<p>- your product breaks, no one notices or fixes it<p>- your product is bad, because your wrote it in a safe boring technology like cobol and therefore couldn&#x27;t access the best developers. (exaggeration, but variations on this are true)<p>My point isn&#x27;t that you must use the newest shiniest tech and infra to do everything, my point is that when people write blog posts like this, they want to make it seem like there&#x27;s a clear line between what&#x27;s &quot;cool shiny tech&quot; and what&#x27;s &quot;hard nosed business focused shipping&quot;.<p>In reality, it&#x27;s a lot fuzzier and these things feed back into each other. For example, you shipped bad code early on to get velocity, but it turned out to be foundational and hard to replace, so your best developers leave as your codebase becomes a ball of mud that it&#x27;s become clear will never be fixed. So now your worst developers are working on a ball of mud and making it worse... etc etc.<p>As always, the answer is that this stuff is hard, and you can&#x27;t make a technology decision by just considering things a user wants to buy and saying everything else is navel gazing and messing around.
评论 #34361883 未加载
评论 #34361747 未加载
评论 #34364178 未加载
yawnxyzover 2 years ago
Well, I just built and launched an HN-like headless forum system running on Sveltekit, Vercel and Airtable. There&#x27;s not really any CI or microservices or anything cool. Of course it&#x27;s not scalable. Is it secure? Probably not... All the account information is just stored on Airtable!<p>BUT this is a system I know, and inspecting and changing data is so easy on Airtable. Managing content is ultra fast. And no, the Airtable API is slow as mud and which is causing my project to be slow as mud. HOWEVER, I launched this version very quickly. Much quicker than doing it on Supabase or SQLite or whatever... because I&#x27;m a designer, and it&#x27;s hard for me to get started on those platforms.<p>If this takes off, somehow, then I&#x27;ll worry about scaling later. Right now I&#x27;ve got a product to launch (and sell)!
migfover 2 years ago
I think this is really misguided.<p>While it&#x27;s true that the stack just enables you build something for people, if you just chase market you have a good chance of piling up technical debt and slowing down before you get there.<p>I have seen far too many projects take twice or five times as much budget as needed because people didn&#x27;t know what they were doing from the get go.<p>Greenfield applications should start with a rough idea of what the technical requirements will be (what ordr of magnitude of users &#x2F; transactions per second) and start by cloning a reference implementation that does what&#x27;s needed. Otherwise you will never get ahead of product.
pickledishover 2 years ago
I have to say I agree very much with his point, though not really the way he communicates it:<p>&gt; Let’s riff. I’ve had my “macho engineer” days, I’ve built that stuff. Take me deep, I’m ready.<p>or<p>&gt; No; customers are not paying for, nor give a shit about, these things. Sorry.<p>Just feels to me a bit condescending for no reason
评论 #34361913 未加载
satvikpendemover 2 years ago
Or said another way: We rewrote everything in $HOTLANG and our startup still failed [0]<p>Some amazing satire on this exact topic.<p>[0] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33555197" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33555197</a>
brapover 2 years ago
So often I see SaaS companies write things like “built with Rust”. Yeah, nobody cares!
评论 #34362345 未加载
dmitriidover 2 years ago
Most of the stuff we used is based on some very boring tech. It may get upgraded to something fancy when the product&#x2F;service scales to a significant number of users, but Spring+Postgres (or RoR, or Django, or PHP...) will get you there with no problems.<p>Facebook was PHP, Instagram was Django etc. They became what they became while using incredibly boring &quot;old-school&quot; tech.<p>The <i>product</i> is paramount, not the tech.
评论 #34364340 未加载
bobleeswaggerover 2 years ago
Most tech stacks are a liability, it&#x27;s not talked about enough.
phkahlerover 2 years ago
Crypto, blockchain, web 2.0, monetization. When the company is the product, any trendy buzzword helps to sell, even if its actively harmful to the &quot;user&quot;.
chrismsimpsonover 2 years ago
Unless of course your product is the stack
asp_hornetover 2 years ago
&gt; No; customers are not paying for, nor give a shit about, these things. Sorry. It’s still cool stuff. It’s just not what you’re selling<p>They sort of are if your bad architecture means features are slower to roll out than your competitors and each release introduces bugs and regressions.
0xdeadbeefbabeover 2 years ago
&gt; A mindset of technology being the means, not the end, is uncomfortable.<p>Really? That&#x27;s pretty funny. How could anyone miss this lesson who has ever used a computer to do things.
评论 #34363126 未加载
victor106over 2 years ago
Amazon’s tech stack did become the product
ETHisso2017over 2 years ago
Counterpoint: Slack
评论 #34362773 未加载
评论 #34362681 未加载
kodahover 2 years ago
&gt; A mindset of technology being the means, not the end, is uncomfortable. But it will help you stay focused on what matters most (the product and your customers), avoid wasteful misadventures, and maximize the company’s chance of success.<p>I&#x27;m wary when I hear this sentiment. At the heart of very versatile companies is a definition of what makes them who they are, both in a product sense and a technical sense.<p>I&#x27;ve worked at very successful companies that wrote their own networking stacks, load balancers, cryptography, service catalogs, paging systems, etc... The stark views of fully embracing a Not Built Here mentality and the &quot;build product and product only&quot; are broken for me. I think executives make bets that authorizing a certain project will add to their direct and marginal gains. Direct gains being cost, performance, ease of use (UX&#x2F;DX), etc... Marginal gains being the experiences that add up over time building custom things or being able to leverage the fully custom parts of your stack.<p>If all you care to have expertise in is the product people see you&#x27;ll miss the products that make that product faster, more secure, and easier to maintain long term.