Hacker News Reader

Comment by feoren | Hacker News Reader

All of these are great except (depending on what exactly you're thinking of):

> 5. "We need bespoke software because our Product is so unique." -- Nope -- use all the tools you can until you have scale, then start to build whatever is least economical to buy.

You're talking about software startups, right? If their product is not "so unique" then why are they building it? If you don't need custom software, why the hell are you hiring software developers? This one is just weird. While I understand the dangers of Not-Invented-Here syndrome, the pendulum is currently WAY too far the other direction. Almost every "modern" software project is way too reliant on dozens of libraries that are philosophically incompatible, spending more time on adapters and API-specific integration than they would spend simply writing what they actually want to begin with.

View on HN

When I arrived at the startup I'm at now, we used a "bespoke" backend for interacting with AWS SQS. It was a pile of code that was written that had no value to the function of the startup.

Switched it to an OSS bus and dumped a bunch of bespoke code. I regret not pushing harder for the CTO to avoid even more bespoke code for some of the admin interfaces that we ended up building for internal tooling which probably would have been better in something like NocoDB.

The value of the startup is rarely in the bits and pieces themselves (very few are), but the process or data flow that the startup models with those bits and pieces and some pain point or business value that gets added in doing so.

One thing I have come to appreciate in startups is that it's better to even spend $10,000 to learn fast rather than to wait 3 months to come to the same conclusion. To put it another way: if you could see 3 months into the future for $10,000, would you pay it? Instantly. So if there's a shortcut that can -- with a high degree of certainty -- remove obfuscations of the path to take, you take it.

I used to work for an automated property valuation platform. It was basically a property valuation workflow tool that presented valuers with the right data at the right time so they could drastically reduce the amount of time spent valuing each property and theoretically produce much more accurate results.

We spent so much time working on features and workflows to interact with clients rather than building the platform for our actual users, the valuers. We could have picked any CRM off the shelf, adopted its way of working, and saved ourselves a lot of time. There is no scenario in which the CRM subscription would have exceeded the cost of the developer's time to produce the cobbled-together half-baked solution we ended up with.

What I meant by bespoke can be illustrated by thinking about an example...

Why are we still hand writing HTTP JSON APIs out of base language primitives in 2023? You can generate correct docs and a skeleton implementation in with JSON Schema and Open API for example. Why spend weeks-months writing endpoints + validation code + docs, when you can define a JSON Schema in slightly more time than it takes to discover what the PM wants to build. You can take it a step further and add the validations to the JSON column in your datastore and now you're correct all the way to the DB.

I feel similarly about most folks who think they can write a better queue than their favorite cloud platform (eg AWS SQS) . Just use the tools that you can buy for pennies on the R&D dollar. The reason a team cannot compete with that is due to amortization. AWS can amortize the cost of development and maintenance across 1000s (millions?) of customers.

This is what I mean by writing bespoke software. not sure if that lines up with everyone else's interpretation.

You can build bespoke software without using bespoke software (other than your own to test or dogfood if applicable of course).

E.g. if it's basically a webapp, the chances that it's such a snowflake that existing frameworks are inappropriate and you need to roll your own are extremely slim.

(On the other hand, you won't think you're making a game and accidentally create Slack that way...)

i don't think gp is talking about building business logic or core product. but like maybe don't roll your own monitoring or log uptake or kanban board / task management solution.

i worked at a company that decided they needed to build their own rdbms because none of the off-the-shelf solutions were going to be able to manage their unique scale. come on.

Reply on news.ycombinator.com