Half the Server Features You Want Are Custom Engineering Projects

📌 Many requested community features are custom software with hosting, maintenance and an owner, not platform settings. Sort every request into native configuration, off the shelf tooling, or custom engineering with a budget line before approving a roadmap. Configuration is reversible. Custom work is permanent overhead.

The request usually arrives fully formed. Someone spent an evening inside a community they admire, saw something that worked well, and wants it. A portal that wraps the chat in a branded shell. A progress tracker members can see. A members area that looks native rather than bolted on. Every one of those is reasonable to want. None of them is a setting. They are software, and the difference between those two categories is where community budgets quietly go wrong.

The costume problem

Feature requests arrive dressed as configuration. They are described in a sentence, they reference something that visibly exists elsewhere, and they sound like a checkbox somebody has not found yet. That framing survives into planning. The wishlist gets approved, a timeline gets built on the assumption that everything on it is a matter of setup, and work begins. Weeks later somebody discovers that item four requires a database, a hosting environment, authentication, and a permanent maintainer.

Nothing about the request was dishonest. It was described by someone who saw the result and had no way to see the build.

What follows is predictable. The timeline slips, the budget conversation reopens under pressure, and the community frequently launches in a half finished state, which does more damage than launching plainly would have.

Run the audit before the wishlist

The fix costs about an hour and happens before anyone commits to anything. Take every request on the list and place it in one of three buckets.

Bucket	Definition	What approval requires
Native configuration	The platform already does this	An afternoon and a decision
Off the shelf tooling	An existing product covers it	Setup time and a subscription
Custom engineering	Somebody has to build and host it	Budget line, timeline, named owner

The sorting itself is the deliverable. Most lists lose roughly half their items during the exercise, either because the platform already handles it or because the requester decides the cost is not worth the outcome once the bucket is visible.

Run the audit with the person who will maintain the result in the room. Scope estimates made without the eventual owner present are consistently optimistic, and the optimism is never discovered until it is expensive.

The recurring cost nobody quotes

A custom build is usually discussed as a one time number. The build is the smallest part of what it commits the organisation to.

• Hosting. Modest, ongoing, and paid whether or not anyone uses the feature.
• Maintenance. Platforms change their interfaces. Dependencies age. Something breaks quietly and stays broken until a member complains.
• Ownership. Somebody has to be responsible. When that person leaves, the feature becomes an orphan that nobody understands well enough to modify and nobody feels authorised to remove.
• Coupling. Once members rely on it, removing it is a product decision rather than a technical one. Custom work is not a purchase, it is a subscription you write yourself. That framing tends to settle debates faster than any estimate.

Why this is a leadership call

The temptation is to treat bucket assignment as a technical detail and delegate it. The permanence argument makes it strategic. Configuration is reversible. A channel structure can be reorganised this afternoon and reversed tomorrow if it does not work. Adopting a platform capability well costs almost nothing to undo. Custom software is close to permanent. It carries obligation from the day it ships, it survives the people who built it, and it constrains future decisions in ways that are hard to see at approval time. Deciding to own software is a categorically different commitment from deciding to use a platform well, and the two should never be signed off in the same meeting.

The reasonable middle path

None of this is an argument against custom work. Some of the strongest community experiences depend on something purpose built, and there are cases where the platform genuinely cannot get there. The argument is about sequencing. Ship the configuration and tooling buckets first, because they are fast and reversible and they will handle more of the wishlist than anyone expects. Let the community run on that for a quarter. Then look at what is still missing with real usage data rather than with impressions gathered from admiring somebody else's server. Most of the time the custom list shrinks again at that point, and the one or two items that survive have a clear justification and an obvious owner. That is a much better conversation to walk into than a budget renegotiation halfway through a stalled build.

The question to ask first

When the next feature request arrives, resist the urge to estimate it. Ask which bucket it belongs in, and then ask what it costs to keep rather than what it costs to build. Those two questions will save more community budget than any tooling decision made afterward.

Communities fail on scope more often than on ideas. Sort the list before you commit to it. More on community infrastructure at danieljeong.org.