A pricing checklist for freelancers shipping DesignSetGo apps to clients

If you are a freelancer or small agency shipping DesignSetGo Apps to clients, the pricing conversation is new territory. The wedge is that you can build the same kind of custom widget in a fraction of the time it used to take, which means the per-unit pricing model you used for “custom WordPress plugin” is wrong now. So is the per-unit pricing model you used for “Vercel-hosted widget with an iframe embed.” Both were calibrated to the old build cost.

A DesignSetGo App costs less to build, costs less to maintain, ships to multiple sites trivially, and creates a different commercial relationship with the client than a custom plugin did. Your pricing needs to reflect that. The answers depend on your business; the questions are what this post is about.

Ten questions to walk through before you send the invoice for a DesignSetGo App engagement.

1. Are you charging for the app, or for the deployment?

If the app is custom to one client, you charge for the build (and possibly the ongoing maintenance). If the app is one you have built before and are deploying to a new site, the “build” is mostly done and you are charging for the deployment, the customization, and the ongoing maintenance.

The wrong shape: charge “build price” every time, including for re-deploys of an app you already wrote. Clients will not catch this immediately, but eventually one of them compares notes with another and the engagement gets awkward. Charge for the work you are actually doing.

The right shape: an itemized invoice that distinguishes “build” line items (one-time, for new apps) from “deploy” line items (recurring, when you ship an existing app to a new client) from “customization” line items (for tweaks to an existing app for this client). Even if the dollar amount is the same, the line-item shape sets up the recurring-revenue conversation.

2. Did you bundle updates?

A DesignSetGo App’s update channel is npx designsetgo apps deploy to a new version. Updates are essentially free in time terms. Are you including future updates in the build price, or charging for them separately?

The wrong shape: silently assume updates are included, then resent every “small change” request. Clients are not telepathic.

The right shape: explicit upfront. “This price includes any updates we cut to the underlying app for the first 12 months. Custom changes specific to your site are billed at $X/hr.” Or: “We charge a $50/mo maintenance retainer that covers all updates and one customization request per quarter.”

3. Did you bill for the second client site separately?

The first time you ship an app you built to two client sites, the temptation is to charge the same price for both. After all, you “delivered” the app to both clients.

You did not, really. The CLI deploy to the second site took 30 seconds. The economic argument for charging the second client the same price as the first is weak.

The right shape: a per-site deploy fee that is meaningfully lower than the original build fee, paired with a maintenance retainer for ongoing support. The second client pays for the deployment, the customization to their site, and the maintenance, not for the build (which was already paid for by the first client). Some agencies charge the second client a higher per-site fee initially, then drop the per-site fee as they amortize the original build across more clients.

The shorter version: the unit you are selling at scale is not “an app.” It is “an app deployment on this client’s site.” Price for the unit you are actually selling.

4. Who owns the bundle?

The legal question. If you build a custom DesignSetGo App for Client A, who owns the source? Client A? You? Both?

This matters more for DesignSetGo Apps than for traditional WordPress plugins because the app is fundamentally a static bundle the client could trivially clone and re-deploy on a different site. If the IP arrangement is unclear, you might find your apps showing up on competitor sites.

The right shape: explicit IP terms in the contract. Some options:

Client owns the bundle, you retain a license to deploy it elsewhere. Common if the client paid full custom-development rates.
You own the bundle, client gets a perpetual license to use it on their sites. Common if the client paid a discount because the app is one you build for multiple clients.
Shared ownership / co-development arrangement. Rare; complicated.

Pick one before you ship. Tell the client which one. Put it in the contract.

5. Is the AI generation part of the deliverable?

If you build the app with Claude Code or Cursor and the client knows that, do they have any expectation that they get the prompt, the harness logs, or the ability to regenerate the app themselves?

This is one of the new questions. Pre-AI, the client paid for your judgment plus your code. Post-AI, the client is paying for your judgment plus the output, but the code is partially Claude’s. Whether the client expects access to the AI-generation steps is a conversation that did not exist five years ago.

For most engagements, the answer is “no, the client gets the deliverable; you do not surface the AI workflow.” But it is worth asking explicitly with the client what they expect, especially if you are charging at custom-development rates.

6. Are you charging for the install dialog UX?

The DesignSetGo runtime ships a permission dialog at install time. For most clients, this is fine: they see the install dialog, they read the permissions, they click install.

For clients who want their version of the install dialog (a custom permission summary, their brand on the dialog, additional copy explaining the app), that is the white-label feature, which is a Pro tier. Are you charging the client for the white-label license, or absorbing it into your service?

The right shape: pass through the white-label cost as a line item if the client wants it; absorb it into your overhead if you are using it across enough clients to amortize it.

7. What is the maintenance contract shape?

The “we will keep this working” promise. For traditional custom WordPress plugins, the maintenance contract was usually framed as “we will fix bugs and apply WordPress compatibility updates for X months.”

For DesignSetGo Apps, the WordPress-compatibility-update concern is much smaller (the runtime handles WordPress version compatibility; the app sees a stable bridge). The bug-fix concern is similar. The new dimension is “we will keep deploying new versions as the underlying app evolves.”

The right shape: explicit contract terms. “$X/mo, includes (a) bug fixes within Y business days, (b) all new versions of the underlying app pushed to your site automatically, (c) up to N hours of customization changes per quarter.”

8. Are you charging for the Connector setup?

If the app uses dsgo.ai.prompt(), the site needs an AI Connector configured. The client may or may not already have one. Setting one up takes 5-15 minutes. Are you charging for that?

The wrong shape: silently set it up using your own API key, then have it expire or hit limits a month in. Now your client’s app is failing and they do not know why.

The right shape: set up the Connector on the client’s WordPress install, using their account with the model provider. They pay the model bill directly. You charge for the setup time as part of the engagement. If they do not have an account with a model provider, walk them through setting one up before you ship the app.

9. Are you charging for client training?

A DesignSetGo App that lives in the client’s wp-admin (or as a block in their pages) is something they may want to use, not just have. If the app has any configuration surface, a non-trivial Gutenberg embed, or a workflow the client’s team will encounter, you should plan for a training session.

The wrong shape: ship the app, send a one-line email, expect the client to figure out how to embed it themselves. They will figure it out, eventually, but the first week of usage will be more support tickets than you expected.

The right shape: a 30-minute training session as a line item. Record it. Send them the recording. The recording will serve future team members on the client side and reduces your future support load.

10. What is your renewal model?

This is the big one. A custom WordPress plugin was traditionally a one-shot deliverable: you built it, you delivered it, you billed it, you were done (modulo the maintenance contract).

A DesignSetGo App engagement is more naturally a recurring one. The app evolves. The site’s content changes and the app should keep working. The runtime updates. New versions ship. The client wants new features that take an afternoon to add.

If you price this like a one-shot delivery, you leave a lot of recurring revenue on the table. If you price it like a SaaS subscription, you may scare off clients who expected a fixed quote.

The right shape (in my experience): an upfront delivery fee that covers the build plus the first deployment, paired with a recurring retainer that covers maintenance, updates, and a small allowance of customizations per period. The retainer is the recurring relationship; the upfront is the entry fee.

The shorter version

The economics of shipping a DesignSetGo App are different from shipping a custom WordPress plugin or a Vercel-hosted widget. The build cost is lower, the per-site deploy cost is dramatically lower, the maintenance cost is lower, and the natural commercial relationship is recurring rather than one-shot.

Your pricing should reflect those economics. The ten questions above are the checklist. The answers depend on you and your clients. The mistake is shipping without asking them.

If you have your own pricing patterns that work, I want to hear them. The category is new enough that everyone is figuring this out at the same time.