People ask fairly often whether I'll build something that doesn't exist yet. The answer is usually yes. This is here so you can work out roughly what you'd be spending before you write to me, rather than having to ask and wait.

Prices below are ranges, not quotes. A small application is at the bottom of a range and something with several moving parts is at the top. I'll give you a real number, in writing, before you pay anything.

Start here: it might not cost anything

If what you want is a feature that would make one of my existing applications better for everyone who owns it, tell me anyway. A fair amount of what's in them arrived exactly that way, from someone saying "it would be good if it also did this." That costs you nothing and you get it in the next update.

It's worth asking first. The rest of this page is for the things that are genuinely yours rather than everyone's.

Four routes

1. Sponsored — from $350

You pay for it to exist. I build it and can sell it afterwards.

You get it free for life, priority support on it, and you shape what goes in it, because you're the one paying for it. It carries no branding of yours and anyone can buy it later.

This is the cheapest route by a distance, and the reason is simple: I end up with something I can keep selling, so you're not carrying the whole cost of building it. If you don't mind other communities having the same thing, this is almost always the right choice.

Typically $350–$800.

2. Built for you — from $700

Your requirements drive it. I keep a general version.

Your features come first, your use case decides the arguments, you're credited if you want to be, and you get direct support from me rather than the queue. I'd still keep a general version of it to sell, but without the parts we built specifically for you.

Most people who think they want something exclusive actually want this. It means the thing is built around your community rather than around a market.

Typically $700–$1,600.

3. Exclusive — from $2,400

Yours, and nobody else's. Ever.

I don't sell it, list it, or reuse it. The first year of keeping it working against Invision Community updates is included, and it's $450 a year after that if you want me to carry on maintaining it.

It costs what it costs for two honest reasons. I'm giving up a product I could otherwise sell for years, and I'm signing up to keep something working through every Invision release from now on, which is a commitment that outlasts the build by a long way. If a quote here feels steep, route 2 usually gets you ninety per cent of what you actually wanted.

From $2,400. A large one will be more.

4. A change to something I already sell — from $80

An extra setting, a widget, a different way of displaying something, a small addition to an application you already own. If it's useful to everyone it's free (see the top of this page). If it's specific to you, it's small money.

Typically $80–$250.

What's included whatever you pick

• No core files are edited. Ever. Everything is built against Invision's own extension points, so an upgrade doesn't break it and you're never stuck on an old version because of something I wrote.

• It's tested on a real Invision install, not a mock. That is how most of the bugs get found.

• It works in light and dark mode, and on a phone.

• Settings in the AdminCP, so you can change your mind later without paying me to change a number.

• Translatable. No English hardcoded where it can't be changed.

• A written scope before any money changes hands, so we both know what "finished" means.

• Support afterwards. A real person reads every message, and that person is me.

What pushes a price up

Worth knowing, because some of these are surprising:

• Anything that needs a program running on a server. This is the big one. Some things people ask for aren't really forum features at all — restreaming audio or video to YouTube, transcoding, anything with a queue of its own. Those need software running continuously on a machine you control. I can build the controls into your site, but the part doing the work lives on your server, and that's a different job with different support attached.

• Third-party services I don't control. If it talks to somebody else's API, that API can change, break, or start charging. Building it is fine; promising it will still work in two years isn't something anyone can honestly do.

• Real-time anything. Live updating without a page refresh needs more than a normal application does.

• Moving data in from another platform. Imports are almost always harder than they sound, because the data is never as tidy as anyone remembers.

• A deadline. I'll usually meet one, but a fixed date means rearranging everything else.

What I'll say no to

• Editing core files. It works right up until your next upgrade, and then it's your problem. I won't leave anyone with that.

• Anything that needs an unlicensed copy of Invision Community.

• Work I can't test. If I can't reproduce it, I can't honestly tell you it's fixed.

• Promising something the platform doesn't allow. If you ask for something and it turns out Invision can't do it, I'll tell you that instead of building an expensive approximation and hoping you don't notice.

How it works

1. You tell me what you want. Plain English is fine. Screenshots of what you're doing now are better than a spec.

2. I ask questions. Usually several, and usually the boring ones, because those are where the price actually lives.

3. I send you a written scope and a fixed number. If the answers change the number, you'll know before you pay, not after.

4. Half up front, half when it's working on your site. Under $400, it's just paid up front.

5. You see it running before the second half is due. If it doesn't do what the scope said, it isn't finished, and I don't consider that a dispute.

I'm one person, so I take on one of these at a time. If I'm mid-way through something I'll tell you when I can start rather than quietly sitting on it.

Fair warning

I build these with heavy AI assistance. I'd rather you knew that up front than found out later. What it doesn't mean is untested — everything runs on this site before it goes anywhere near yours, and it's built against a real Invision install rather than a mock.

To start

Message me here, or use the contact form. Tell me what you're trying to do rather than how you think it should be built — quite often there's a simpler route, and occasionally the answer is that something already does it.

With that being said I have migrated the support forums here to Invision Community 5 so that way it just makes it easier for me to run everything under here as Invision has more options available to me to support both.

I look forward to continuing to build and support the Flarum extensions you know me for but also building some of them for Invision as well. Thank you to everyone that supported me on Flarum and I will not be going away.

We believe in being straight with the people who use our themes and extensions, so here it is: every theme and extension we ship is built with vibe coding. All of it.

If that word makes you nervous, or makes you roll your eyes, this post is for you. We want to make the honest case for why it's a great way to build — and be just as honest about the ways it goes wrong when people don't respect it.

What "vibe coding" actually means

Vibe coding is building software by describing what you want in plain language and letting an AI assistant write the code, then steering it conversationally — "make the buttons bigger," "now add a dark-mode toggle," "that broke the sidebar, fix it" — instead of hand-typing every line yourself.

You're still the one in charge. You're still making every decision about what gets built, how it behaves, and whether it's good enough to ship. You're just spending your time on the what and the why instead of the boilerplate.

⚡ Why it's good — for those still on the fence

It's fast where speed actually matters. Ideas that used to sit in a backlog for months can be prototyped in an afternoon. That means more features, more often, and bugs fixed while they're still fresh.

Iteration becomes cheap. When changing something costs minutes instead of hours, you experiment more. You try the bold version of an idea instead of the safe one, because if it doesn't work you just try again.

It frees you to focus on the experience. The hours not spent wrestling with boilerplate go into the things you actually feel as a user: the layout, the polish, the little touches that make an extension a pleasure to use.

It lowers the wall. A great idea for a theme or feature no longer dies just because someone didn't have ten years of framework experience. More good ideas get to exist.

It keeps the big picture in view. Describing a feature in plain language forces you to be clear about what it should do — which, honestly, is where most software goes right or wrong long before the first line of code.

If you've been on the fence, the short version is: it lets a small operation move like a big one, and ship things that are genuinely good.

⚠️ The harms — for those who don't use it properly

This is the part people skip, and it's exactly why vibe coding gets a bad reputation. Used carelessly, it can ship real damage:

Shipping code you don't understand. The single biggest trap. If you can't explain what a piece of code does, you can't tell when it's quietly broken — and you definitely can't fix it under pressure when something goes wrong on someone's live forum.

Security holes you never see. AI will happily write something that works but leaves a door open — missing permission checks, unsanitized input, leaky endpoints. For an extension that runs on other people's communities, that's not a small mistake.

Invisible technical debt. Code that looks fine and runs fine can still be a tangled mess underneath. Skip the review and you build a tower that gets harder to change with every "just add one more thing."

Confidently wrong answers. AI sometimes invents functions, settings, or APIs that don't actually exist, and states it with total confidence. Without testing, those land straight in a release.

"It worked on my screen." Generated code often handles the happy path beautifully and falls apart on the edge cases — the empty list, the weird timezone, the user with 4,000 notifications. Skipping testing means your users find those edges for you.

The pattern in every one of these is the same: the harm doesn't come from using AI to write code. It comes from abdicating judgment — treating the output as finished instead of as a first draft.

✅ How we do it responsibly

We vibe code everything, and we still sleep fine, because we treat the AI as a very fast junior developer — not an oracle:

We read and understand every line that ships. If we can't explain it, it doesn't go out.

We test against the messy real world, not just the happy path — odd inputs, big forums, light and dark themes, missing optional dependencies.

We sweat security on anything that touches permissions, user input, or data.

We own the result. When something breaks, "the AI wrote it" is not an excuse — it's our name on the extension, and our responsibility to fix it.

That's the whole philosophy: vibe coding gives us speed; judgment keeps it safe. Drop either half and you get something worse than not using it at all.

We're proud of how we build, and we think the results speak for themselves across our themes and extensions. If you've got questions about any of this — or you're curious how a specific feature came together — ask away. We're happy to talk about it.

</ernestdefoe·online>