Which is better, creating a platform from scratch or extending an off the shelf base product?

Both && Neither.

Built from scratch means it is literally what the business wants, however it becomes a burden to support and add things to and creates a learning curve for future devs.

Off the shelf means the business needs to be adaptable and accept not everything they want can be done.
However you can probably find devs that have worked with the product and assist in future maintenance.

There's pros and cons to both sides.

As always: It depends!

Depends on how design focuses the team is.

It's a nightmare to work with a design driven team where the designers call the shots and the team is willing to make devs spend ages to customise a base product feature that really was never meant to be changed. can take longer to tweak a detail than it would've taken to build the feature from scratch.

When it comes to maintainability I'd say it's 50-50

Seen some projects rot cause they were tightly coupled to an old version of a bade project. Seen others survive as new devs familiar with the base product could get into it quickly.

Ultimately comes down to how complicated the features are. Some things are not worth doing from scratch. Like datepickers and image editors.

Sometimes the best route is going a middle route where you buy a slim product for the most complex feature and do the rest from scratch

Use the correct tool for the job

Depends on what kind of 'off-the-shelf' solution we're talking about. A webpress/joomla kind of solution that requires next to no code from you, or more like a framework, that takes control of your app and enforces code/project structure you're writing.

Take-and-use solution (WP-like):

cheap and not at all flexible. Dig deep into its feature sets and possible limitations. If you are not planning to expand beyond those -- go with the off-shelf solution.

Framework:

For a PoC or an MVP it's probably easier to go with an off-shelf solution. If that MVP is likely to evolve further, design your code so you could painlessly remove the off-shelf soln and replace it with a custom one.

Extending the take-and-use tool: if it's designed to be extended - consider it as a framework.

Just my 2¢

It depends, but from a business perspective I can say: Don't develop what you're not selling. Because you won't have the resources to do it for free.

For example: If you build common hardware, don't write drivers. Use standardized and existing drivers where possible. If you have special features, then there is no way around. But then your selling point should be the added features.

@tHe-jAsE is that also how you approach a job in a new company

@HerrNyani Good point. I like that quote. "Don't develop what you're not selling."

In a scenario where your team mixes working on money-making products and stuff that's internal to the company - if management needs to prioritise, it's likely they'll say "forget about the internal stuff, focus on the money-makers". Then it'll feel bad for the dev team who built the internal stuff that they're not given time to maintain. "Why did we build this from scratch when we should've assumed we wouldn't have time to keep it up to date"

As everyone already said, it depends, building from scratch also mean you get to write the whole documentation yourself, which I find to be a relaxing task to do yet many despise it for being boring.

Tastes and colors as they say!