Sample proposal for a trading software project
This is a sample of the format, written for a fictional project. Client A and Exchange A do not exist, so this is not a real client and there are no real results here. It shows how a scope document becomes work items, approvals and a fee basis. Cost, dates and contract terms appear as placeholders: nothing on this page is a price or an offer.
Sample, fictional project. Text in [square brackets] would be filled in for a real project. The proposal is what you receive in the second stage of how we work, and development starts only once you approve it. It follows the sample scope document.
| Prepared for | Client A (fictional) |
|---|---|
| Project | Order service for Client A on Exchange A |
| Based on | Scope document version 1.0 and rule document version 1.2 |
| Prepared by | Fincode |
| Date | [date] |
| Valid until | [date] |
| Total cost | [amount in the real proposal] |
1. Summary
Fincode proposes to build the order service described in scope document version 1.0: software that applies Client A's written rules, on Client A's own Exchange A account, with its own API key, on its own server.
The work runs in five milestones. Each one ends with something Client A can read or run, and the next starts only after Client A approves it. Testing happens on Exchange A's testnet first, then in a paper trading account with live market data. The switch to a live account comes last, with small limits that Client A sets, and only after Client A has approved the test report.
Fees depend on scope and effort, not on trading volume or results.
2. What Client A receives
- The order service, as specified in the scope document, with source code and deployment scripts.
- Something to read or run at the end of each milestone, as listed in section 3.
- A test report covering every acceptance check in the scope document. See the sample test report.
- Technical documentation and an operations runbook covering start, stop, restart, key rotation and releasing a freeze.
- A live system on Client A's server, after approval.
3. Milestones and plan
Check IDs refer to section 10 of the scope document. A milestone is done when its checks pass and Client A approves it, not when a date arrives.
| Milestone | What Client A can read or run | Done when | Date and cost |
|---|---|---|---|
| M1. Design and test harness | A design note, and a harness that sends test instructions and injects failures on the testnet | Open questions Q1 to Q5 are answered, and Client A approves the design note | [date], [amount] |
| M2. Intake and risk gate | Intake and risk gate running on a test server. Blocked orders appear in the log | T03, T04, T05 and T11 pass | [date], [amount] |
| M3. Order manager and adapter | Orders placed, tracked and queried on the testnet | T01, T02, T08, T09, T10 and T14 pass | [date], [amount] |
| M4. Rule module, reconciliation and restart | The full service running against the testnet, and a draft test report | W01, T06, T07, T12 and T13 pass | [date], [amount] |
| M5. Paper trading and go-live | The paper trading trace, with no return figures, the final test report and the runbook. Then a gradual go-live with small limits | P01 passes, and Client A approves the test report and the switch to live | [date], [amount] |
4. How the fee is set
The fee comes from the work items above. It does not depend on trading volume or results: no share of profit, no percentage of volume, and nothing that changes with how the rules perform.
| Item | In a real proposal |
|---|---|
| Total cost | [amount in the real proposal] |
| Currency and taxes | [agreed in the contract] |
| Payment terms | [agreed in the contract] |
Costs that stay on Client A's own accounts are not part of the fee: the server, exchange fees and any paid data feed.
5. Assumptions
The plan holds while these remain true. If one stops being true, it is handled as in section 8.
- The rule document stays at version 1.2 through go-live, because every check is run against it.
- One exchange, one account and the instruments listed in the rule document.
- Exchange A's testnet is available and supports the order types the rules use. Open question Q5 confirms this.
- Exchange A's API and API terms stay as read on [date].
- Client A supplies a testnet key before milestone M1, and worked cases and limit values before milestone M2.
- A named approver at Client A reads each output. Time to respond: [agreed in the contract].
6. Approvals
Nothing moves to the next stage on its own. These are the points where work waits for a named person at Client A.
| Point | What is approved | Until then |
|---|---|---|
| Before M1 | This proposal | No development starts |
| End of M1 to M4 | The milestone's output and its check results | The next milestone does not start |
| During M5 | The test report, the live limits and the switch to a live account | The software does not touch a live account |
7. Delivery risks
These are risks to the project, not to any trading result, which this proposal says nothing about.
| Risk | Effect | How it is handled |
|---|---|---|
| A rule cannot be coded as written | Work on that rule stops | The question goes to Client A in writing. Fincode does not choose an interpretation |
| Exchange A changes its API during the project | Rework in the adapter | The changelog is checked at each milestone. Work outside the scope becomes a numbered change |
| Exchange A changes its API terms | The project may not be able to continue as scoped | The terms are read again before go-live, and any change is raised at once |
| The testnet is reset or behaves differently from the live exchange | Tests must be rerun, and fill behavior stays unknown | Test data is rebuilt by script. Live fills are compared with exchange records under small limits |
| Client A's server is not ready | Go-live waits | Server requirements are delivered at the end of M1 |
| An approver is unavailable | The stage waits, and later dates move | A deputy is named at the start of the project |
8. If the scope changes
A change is written as a numbered change to the scope document, with its effect on work items, dates and cost. Work on it starts only after Client A approves it. A new version of the rule document counts as a change, because the checks depend on it.
9. After go-live
In the initial period, [length agreed in the contract], Fincode watches the software's technical operation, not positions or decisions. Maintenance after that is optional. It covers the software and API compatibility, not strategy changes or position monitoring. Its scope and cost: [agreed in the contract].
10. Terms set in the contract
This sample leaves these open on purpose. A real proposal points to the clause in the contract.
| Term | Position |
|---|---|
| Code ownership | [agreed in the contract] |
| Confidentiality | [agreed in the contract] |
| Bug-fix period after delivery | [agreed in the contract] |
| Reply times | [agreed in the contract] |
| Liability and governing law | [agreed in the contract] |
11. What this proposal does not promise
- That the rules will make money. Tests show how the software behaves, not future results, and trades can lose money.
- That the software can never fail. Outages caused by the exchange, the server or the connection cannot be ruled out entirely, which is why monitoring and an emergency stop are in scope.
- Advice on rules, instruments or parameters. Fincode does not recommend strategies, and strategy and investment decisions belong to Client A.
Orders are sent by the software, on Client A's own account, with its own API key, under the rules it defined. Fincode is a software company and does not provide investment advice, portfolio management or crypto asset services.
12. Approval
| Role | Name | Date | Decision |
|---|---|---|---|
| Client A approver | [name] | [date] | [approved, or changes requested] |
| Fincode | [name] | [date] | [issued] |
Sample of the format for a fictional project. It is not an offer, and it states no Fincode price.
What to look for in any proposal
You can hold any quote to these tests, whoever sends it.
It points to a written scope
A price with no scope behind it cannot be compared with anything. Ask what document the number was built from.
Milestones end with output
Each one should end with something you can read or run, and a check that says when it is done.
Assumptions are stated
Every estimate rests on some. If none are listed, you will find them when they fail.
Failure testing is priced in
Check that duplicate orders, dropped connections and restarts appear in the work, not only the normal path.
The fee does not depend on results
A developer paid on your profit has a stake in your trades. Be careful with any fee tied to returns or volume.
Questions about proposals
Is this a real proposal?
No. Client A and Exchange A are fictional. The page shows the format of a proposal, not a real client, a real result or a real price.
Why is there no price on this page?
Cost is set for each project, from the work items in its own scope. You see the work items, dates and cost in your written proposal, before development starts.
When does development start?
Only once you approve the written proposal. It shows the work items, dates and cost, so you can decide before anything is built.
What if my exchange's API terms do not allow what I want?
Each platform's terms are checked before we quote. If a clause blocks your use, we say so first.
Can the fee depend on how the software performs?
No. Fees depend on scope and effort, not on trading volume or results. Fincode does not take a profit share.
Read the other documents
Want a written proposal for your project?
Send a short brief with the platform you use, what the software should do and your timeline. You do not need to share your rules yet. Fincode is a software company and does not provide investment advice, portfolio management or crypto asset services.