> In more of a work context, I think internal tooling for specific users or teams can feel similarly empowering. When you have an intentionally-constrained set of users, finding product-market fit and making sure the solution actually works for their needs becomes the only goal. And with so few users, it’s easy to keep tabs on what is and isn’t working for them.
I've seen a few of these and they always fall into (non-)maintenance hell once the dev (it's always just one, because the business can't spare a whole team for something like this) leaves, or until the next re-org (read: almost certainly less than two years from any random point in time) when the responsibilities of the team it was built for are divided among other teams, or outsourced to a body shop like CapGemini that won't use it (because they can replace the functionality with an army of managers with spreadsheets, all of which they can bill for).
In short, I think it's largely a fantasy to develop custom software for small userbases on economic grounds (at least for nontechnical users using typical "real" stacks -- spreadsheets and "programmer tools" are a different story), which is kind of the point of this piece.
I've seen a few of these and they always fall into (non-)maintenance hell once the dev (it's always just one, because the business can't spare a whole team for something like this) leaves, or until the next re-org (read: almost certainly less than two years from any random point in time) when the responsibilities of the team it was built for are divided among other teams, or outsourced to a body shop like CapGemini that won't use it (because they can replace the functionality with an army of managers with spreadsheets, all of which they can bill for).
In short, I think it's largely a fantasy to develop custom software for small userbases on economic grounds (at least for nontechnical users using typical "real" stacks -- spreadsheets and "programmer tools" are a different story), which is kind of the point of this piece.