Will marketplaces actually pay our royalty?

Some will, some will not, and that is outside anyone's control including ours. EIP-2981 lets your contract declare what the royalty is and who receives it, which is a standard for asking rather than a mechanism for enforcing. Several major marketplaces have made royalties optional for sellers. We will implement the standard properly and we will not let you plan revenue around it.

Who pays for IPFS pinning after the project ships?

You do, on your own account, and that is deliberate. Pinning is set up under your Pinata or storage account rather than ours, so the files stay yours if we never speak again. The handover states plainly that the account has to remain active and what the monthly cost is, because an unpinned collection quietly stops resolving and the first you hear of it is empty boxes on a marketplace.

Do you produce the artwork?

Artwork can be supplied by you or commissioned, and which of the two applies is one of the larger swings in the quote. What we always own is the pipeline — generating correctly formatted metadata for every token, validating that every required field exists, uploading and pinning both images and metadata, and verifying the result against the deployed contract.

Is an NFT the right format for a membership pass or a ticket?

Sometimes, and the honest test is whether the holder benefits from the record living outside your systems. A pass that people should be able to hold, show and keep even if your platform changes is a reasonable fit. If the only requirement is that your own database knows who is a member, a normal database does that faster, privately and for less, and we will say so.

What happens on launch day if something goes wrong?

Launch-day support is a defined line item with agreed hours, and the plan is written before the day rather than improvised on it. The realistic failure modes are known ones — RPC congestion, wallets on the wrong chain, a phase opening earlier than intended — and the response to each is decided in advance. A rehearsal mint is executed before the public phase opens.

Can we change the mint price or supply after launch?

Only if the contract was built with a setter for it, and only within limits stated at deployment. This is decided during the specification, when we ask which values could realistically need to move. Anything without a setter is fixed forever, and the alternative is deploying a second contract with a new address, new verification, new listings and holders split across two collections.

Blockchain & Web3

NFT collection and minting site

Contract, metadata pipeline and mint site built together — with pinning on your account and a script that proves every token actually resolves to a real image.

From: $1,500–$15,000
Typical time: 3–8 weeks
Usually bought by: Creators, brands

What this actually solves

The market people picture when they hear NFT — pictures bought speculatively and resold higher — is not what teams commission now, and any studio still selling that story is selling you something it cannot deliver. What gets commissioned instead is more useful and considerably more boring. Membership passes for a gym, a coworking space or a course. Tickets whose transfer rules you actually control. Loyalty items for a brand. Items inside a game. In all of these the customer is not buying art. They are buying something that sits in their own wallet, that they can show to somebody else, and whose existence does not depend on your CRM still being subscribed to next year.

The work is more involved than it looks from outside, which is where most of the trouble starts. If you are picturing a contract and a button, the actual delivery is a contract, a metadata pipeline, permanent storage that genuinely stays available, an allowlist mechanism, a website that connects wallets and handles every way that connection can fail, a full rehearsal on a testnet, and somebody present on launch day. Getting any one of those wrong is visible to the public and, on a deployed contract, frequently permanent.

How the build runs

Phases, supply and rules on paper. How many, in what tiers, at what price, in what order, who gets early access, and — most importantly — which of those values might need to change after launch, because those are the only ones that will get setters. Chain choice is made here on fees and where your audience already is. Three to five days.
Contract and allowlist. Built on OpenZeppelin's ERC-721 or ERC-1155 with the controls that matter — maximum supply, per-wallet limits, a base URI setter, a withdraw function and EIP-2981 royalty declaration. Allowlists are done with a Merkle root rather than by writing thousands of addresses on-chain, so the chain holds one small fingerprint and each buyer brings a proof that they were on the list. Tests cover the phase transitions, the limits and the failure cases. One to two weeks.
Metadata and storage, then verification. Every token's JSON generated in correct ERC-721 format from your source data and validated field by field, images and metadata uploaded and pinned to IPFS on your own account, and image references written as ipfs:// URIs rather than gateway links. Then the step almost nobody does — a script that takes the deployed address, calls tokenURI for sampled tokens, resolves each URI through a public gateway, fetches the JSON, checks every required field, fetches the image, and confirms it returns a real image rather than a 404 or an HTML error page, printing a pass or fail table. Four to eight days.
Mint site. Next.js with wagmi and RainbowKit, and the states that separate a working mint from a demo — no wallet connected, wallet on the wrong network, transaction rejected by the user, transaction pending for a long time, allowlist proof not found, per-wallet limit reached, phase not open yet, and sold out. Each of those gets a real screen, because on launch day every one of them will happen to somebody in the first minutes. One to two weeks.
Testnet rehearsal driven by outsiders, then mainnet. The whole flow on a testnet, minted by you and by at least one person with no involvement in the project, because the mistakes they make are the mistakes your buyers will make. Then mainnet deployment from a written runbook, contract verified, parameters read back off the chain, ownership on your multisig, a rehearsal mint before the public phase, and the staffed launch window. Five to nine days plus the agreed support hours.

What moves the price

Whether artwork exists. A finished set of images with a clean attribute sheet is one job. Commissioning, generating or reworking art so it produces consistent, correctly attributed metadata is a much larger one, and it is the single biggest swing in this range.

How complicated the access rules are. One public mint is simple. Three phases with different prices, different per-wallet limits, separate allowlists per tier and a delayed reveal multiplies the contract logic, the front-end states and the number of things that can be misconfigured on the day.

How much of launch day you want covered. A defined support window, monitoring, and an admin dashboard so you can open and close phases yourself all sit at the upper end. The range is $1,500–$15,000 over 3–8 weeks, and a real testnet rehearsal is what pushes a first project toward the upper end of that window.

What usually goes wrong

The metadata is uploaded to IPFS but never actually pinned. Months after launch the images vanish and marketplaces start showing empty boxes. IPFS is not hosting — it is an addressing system, and if no node is holding the file then the file is nowhere. The other version of this mistake is pinning on somebody else's account, which turns your collection into a hostage to a subscription you do not control. Pinning belongs on your account, with the ongoing cost stated in the handover.

The base URI points at something that can expire. Setting it to your own web domain, or to a public gateway URL rather than an ipfs:// URI, works perfectly on launch day. Then a domain renewal is missed or a free gateway changes its terms, and every token in the collection resolves to nothing simultaneously. It is entirely preventable and it is checked by the verification script rather than by eye.

The mint site is only ever used by the people who built it. They connect the right wallet, on the right network, with enough balance, and press the button once. Real traffic arrives on the wrong chain, rejects the first transaction, opens two tabs, refreshes mid-transaction, and hits a sold-out contract that still shows a live button. Those are not edge cases on a mint day, they are what a mint day is made of, and the fix is to build a screen for each one and rehearse with somebody from outside the project.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Will marketplaces actually pay our royalty?: Some will, some will not, and that is outside anyone's control including ours. EIP-2981 lets your contract declare what the royalty is and who receives it, which is a standard for asking rather than a mechanism for enforcing. Several major marketplaces have made royalties optional for sellers. We will implement the standard properly and we will not let you plan revenue around it.
Who pays for IPFS pinning after the project ships?: You do, on your own account, and that is deliberate. Pinning is set up under your Pinata or storage account rather than ours, so the files stay yours if we never speak again. The handover states plainly that the account has to remain active and what the monthly cost is, because an unpinned collection quietly stops resolving and the first you hear of it is empty boxes on a marketplace.
Do you produce the artwork?: Artwork can be supplied by you or commissioned, and which of the two applies is one of the larger swings in the quote. What we always own is the pipeline — generating correctly formatted metadata for every token, validating that every required field exists, uploading and pinning both images and metadata, and verifying the result against the deployed contract.
Is an NFT the right format for a membership pass or a ticket?: Sometimes, and the honest test is whether the holder benefits from the record living outside your systems. A pass that people should be able to hold, show and keep even if your platform changes is a reasonable fit. If the only requirement is that your own database knows who is a member, a normal database does that faster, privately and for less, and we will say so.
What happens on launch day if something goes wrong?: Launch-day support is a defined line item with agreed hours, and the plan is written before the day rather than improvised on it. The realistic failure modes are known ones — RPC congestion, wallets on the wrong chain, a phase opening earlier than intended — and the response to each is decided in advance. A rehearsal mint is executed before the public phase opens.
Can we change the mint price or supply after launch?: Only if the contract was built with a setter for it, and only within limits stated at deployment. This is decided during the specification, when we ask which values could realistically need to move. Anything without a setter is fixed forever, and the alternative is deploying a second contract with a new address, new verification, new listings and holders split across two collections.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about NFT collection & minting site All Blockchain & Web3 services