Guides / Builder fieldwork
Research you can put to work

How to Scope a Bitcoin Freelance Project

A useful service offer names a specific outcome, the evidence that proves it and the work included. Start there before discussing a price or delivery date.

By Bitcoin CV · Published 14 September 2026

This guide is for developers, designers and people commissioning Bitcoin work. It provides original planning examples, not offers from listed companies. Bitcoin CV does not yet process bookings, payments, CV uploads or disputes.

1. Replace the broad promise with an observable outcome

“Build a Bitcoin app” leaves almost every decision open. A tighter brief might read: “Prototype a merchant payment screen that shows pending, confirmed and expired states, then provide annotated components and a handover session.” Name the intended user, starting point and deliverable. Explain what a reviewer will be able to see or run.

Choose the engagement that fits the uncertainty. A short discovery phase can produce a requirements note and technical plan when dependencies are unclear. A fixed deliverable works better when the environment and acceptance checks are already understood. Ongoing maintenance needs an owner, response expectations and a clear change process.

2. Package a service around evidence

These examples are starting points to adapt with a client. They do not establish market demand, standard prices or typical completion times.

Service ideaDeliverableAcceptance example
Payment UX prototypeAn interactive flow, component states and handover notes.A reviewer can complete the task and distinguish waiting, paid and expired without relying on color alone.
Lightning integration discoveryA state model, API mapping and local proof of concept.The demo handles one successful payment and an agreed failure case; setup steps work from a clean environment.
Bitcoin test harnessA reproducible local network and focused regression scenario.Another developer can rerun the scenario and obtain the documented result using recorded versions.
Developer documentation repairA corrected guide, working example and tested-environment notes.A fresh user can complete the documented task, and unsupported assumptions are explicitly listed.
Wallet recovery UX studyA research plan, annotated prototype and technical questions.The prototype explains who can act, when a path is available and what happens next. Engineering validates policy claims.

For technical starting points, the Core Lightning documentation covers application and plugin development, while Nigiri packages a regtest environment. Tool availability does not make a prototype ready for a production wallet.

3. Write the boundaries before estimating

Record the chosen wallet or node implementation, versions, supported platforms, expected integrations and test network. List what the client supplies: designs, API access, a staging environment, sample data and a person who can make decisions. A missing dependency should change the schedule visibly.

Separate prototype, production implementation and ongoing operation. For a payment prototype, exclusions might include real-fund operation, new cryptography, custody architecture, compliance assessment and 24-hour support. These are examples to discuss, not a standard contract. Security-sensitive work requires the relevant expertise and a separately agreed review.

Specify information handling. Demonstrations should use test data; credentials belong in an agreed secrets system, not a public repository or portfolio. Decide who owns access, who can authorize deployment and how access is removed at handover.

4. Make acceptance testable

Write an acceptance check as a situation and an observable result. “The interface is intuitive” is hard to settle. “When the request expires, the screen shows that state, prevents reuse of the expired request and offers the agreed next action” gives both sides something concrete to inspect.

Distinguish delivery from someone else’s decision. You can deliver a documented patch and respond to review; you cannot guarantee that an open-source maintainer merges it by a deadline. Likewise, a design study can provide evidence and recommendations without guaranteeing a business conversion rate.

5. Agree on feedback, changes and handover

Name a reviewer and the format of each milestone review. Record how many revision rounds are included and what counts as a change in scope. For a new request, describe its effect on work, timing and price before starting it. Keep a short decision log so remote collaborators have the same context.

At handover, provide the deliverable, setup instructions, dependency versions, tests or observation notes, known limitations and ownership information. Agree on the applicable license and what may appear in a public portfolio. If ongoing operation is involved, identify the person responsible for monitoring, upgrades and incidents.

6. Make the first message specific

When a team has invited proposals or you have an appropriate contact, lead with the problem you understand and the evidence you can show. Offer a small next step: reviewing a brief or clarifying a dependency. Respect the recipient’s published instructions. A company directory entry alone is not an invitation to pitch.

“I built a local example of the payment-state issue described in your brief. Here is the demo and its limitations. I propose a discovery milestone that produces a state model, an integration plan and agreed acceptance checks.”

This is an editable example; use it only when it accurately describes your work and the conversation.

Write the brief before the quote.

Use the worksheet to record outcomes, deliverables, dependencies, review steps and handover. It stays on your device and is not submitted to Bitcoin CV.

Download project-scoping worksheet ↓

Sources and related reading

The service packages and acceptance examples are original Bitcoin CV editorial guidance. Technical references were checked on 14 September 2026: Core Lightning documentation and Nigiri’s project repository. Explore the builder opportunity map for more source-linked directions and the project planning page for the site’s marketplace plans.

All guides → · Builder resources →