The repository has no README. The last commit is fourteen months old and its message is "fix." The previous developer is not returning emails, the client is not sure who owns the hosting account, and they would like a fixed price for "adding the booking feature," which they believe is small.
Development is the one freelance trade where the estimate is openly a bet, and everyone in it knows that. The machinery around the bet is what decides whether the bet pays.
Estimating what you cannot see
A fixed price on unfamiliar code is a guess with your margin as the stake. The move that experienced developers make is to sell the look before the bet: a paid audit of a day or two, at a stated price, whose deliverable is a written assessment and a fixed quote for the build. The client gets a number that is worth something. You get to open the repository before you commit to it.
Hourly billing is defensible on genuinely murky work, and a rescue job on someone else's half-finished system is the textbook case. The trouble is that hourly never converts back to a project once the shape is visible. The audit is how you earn the right to quote fixed, and the fixed quote is how the engagement acquires an end.
Access, and the week that vanishes
The timeline says the work starts Monday. The database credentials arrive the following Thursday, the hosting login the Tuesday after, and the API key for the payment provider is with someone on holiday. Nobody did anything wrong and the project is two weeks late.
The agreement needs one sentence: the client supplies access to the systems named in the scope before the start date, and the timeline is conditional on it. Then a late login moves the date instead of blaming the developer. At the other end, a sentence that says what happens to the credentials you hold at handover, returned or revoked, because a freelancer holding production keys a year after the project is a liability for both of you.
The client who vanishes with the code
This is the one that matters most. Once the code is in the client's production system and the invoice is unpaid, you are not negotiating. You are asking. The sequence that prevents it is not clever: a deposit before work begins, delivery in stages that are each invoiced, and the final merge or the final deployment held on a branch or a staging environment you control until the last invoice clears. Handover of credentials is the last stage, not the first.
Scope needs the same treatment as any other trade, with a developer's vocabulary: the features named and counted, the integrations listed, the browsers and devices supported, the tests included, the environments delivered to. "Add the booking feature" is not scope. "A booking flow of four screens, integrated with the existing calendar API, deployed to staging, with a support window of two weeks after launch" is.
The audit and the build, on paper
North was tuned against visual design work, and the sentence is worth saying plainly: it knows what a revision round is better than it knows what a pull request is. What it does know is the machinery of a client project, which does not change with the deliverable.
You paste the notes from the call. North drafts the proposal as options that differ by phase rather than by price: the paid audit; the audit and the build; the build with a support window. Inside each the scope is counted (the screens, the integrations, the environments, the support window in weeks) and each item has a sentence about what it does for the business, drawn from the call. The terms note names the assumptions the price rests on: access supplied before the start date, one named person for feedback, decisions returned within a stated number of working days.
You edit it and press send yourself; the client reads it at a private link, accepts an option, and is shown the agreement, drafted alongside from the same scope, which they sign after a one-time email check. After signing, the accepted option can become stages with dates (audit, build, staging, production handover), which the client watches from the room, and which become invoice lines as you tick them off; the final invoice remembers what the audit stage already billed. Stages, and card payment on your own Stripe account, are part of the paid plan; the invoices, the reminders you choose to send, and the room are not. The production handover can be the last stage, and its invoice can be the last thing that happens before the merge.
If you bill by the hour and intend to keep billing by the hour, North's proposals are the wrong shape. They are fixed options with totals. Use it for the engagements with edges, which the audit is designed to create.
What North does not touch
North does not track time, does not connect to a repository, and does not run an issue tracker. It does not hold credentials, deploy anything, or know what the code does. There is no rate guide for development on this site, because the pricing surveys we could verify were for design work and we would rather not invent one. What North holds is the paper that says what was bought, when access was due, and which stage the production keys change hands in.
Common questions
- Should a freelance developer quote a fixed price on code they have not seen?
- No. Quote a short paid audit first (a day or two at a stated price), whose deliverable is a written assessment and a fixed quote for the build. The client gets a number they can trust instead of one you invented; you get to see the codebase before you bet on it. A client who refuses to pay for the audit has told you how the rest of the project will go.
- How do I protect myself if the client disappears before paying for the final work?
- Deposit first, then deliver in stages that are each invoiced, and keep the final deployment or the final merge behind the final payment; a licence clause that says the code is licensed rather than owned until the balance clears gives that sequence teeth. Work on a branch or a staging environment you control until the last invoice clears; the handover of credentials and the merge to production are the last stage, not the first. A client who has the code and has not paid is a client you are asking, not negotiating with.
- What should a freelance development contract say about access and credentials?
- That the client supplies access to the systems named in the scope before the start date, that the timeline is conditional on it, and that any credentials you hold are returned or revoked at handover. Waiting a week for a database login is the most common way a development timeline slips through nobody's fault, and a sentence in the agreement is what turns that week into a moved date rather than a missed one.