The short version
You’ll have a deployed release that covers the agreed scope, plus a repo with tests, clear setup docs, and a runbook so your next developer can keep shipping without guessing.
I’ll turn your backlog into a scoped technical brief, ship a first release, then harden it with a stabilization sprint. You’ll get working software you can keep changing without fear. Next up: scope, timeline, and a fixed price.
I start by turning your backlog into a short plan with acceptance checks, edge cases, and the risks called out in plain language. Then I ship an end to end first release early, so you can click through real flows and adjust priorities before I build deeper. Each week you’ll see what shipped, what’s next, and what changed.
About me
I’m Marc Beaulieu, a software developer at Beaubien Software. I build and extend web apps, mobile apps, APIs, and databases for small to mid-sized teams that need one release to land, fast. Most of my work starts with an existing product and a backlog that has outgrown the time available.
I’m the person writing the code, reviewing the pull requests, and answering the hard questions. I keep scope tied to acceptance checks, I put tests around the code that is most likely to break, and I’ll say "no" when a shortcut creates a future bill you can’t see yet. You’ll always know what is done, what is risky, and what is slipping.
Selected work
A few recent builds where the brief was "ship the next release" and the job was keeping the code safe to change afterward.
Portfolio
Backlog-to-release web app. Took a crowded backlog and shipped a first release in 6 weeks, then followed with a stabilization sprint that cut repeat bug reports by 40% over the next month.
Mobile app feature rollout. Added a paid feature to an iOS and Android app without breaking existing onboarding. Released in two phased launches, with crash-free sessions staying above 99%.
API rebuild and integration. Replaced a brittle integration with a versioned API and background jobs. Reduced timeout errors from daily to rare, and added alerts so failures show up in minutes.
“They shipped what mattered, and the code was easy to extend afterward.”
Product manager, a small SaaS company
Technical brief
A short written plan that lists the scope, acceptance checks, key risks, and the decisions needed from you before build starts.
BACKLOG AND MILESTONES
A prioritized backlog with milestones tied to what will ship, so weekly updates map to items you already care about.
SOURCE CODE REPOSITORY ACCESS
A Git repo you can access from day one, with a clear structure and a README that explains how to run the project locally.
Deployed release
A working release deployed to the agreed environment, with the core flows verified against the acceptance checks in the brief.
AUTOMATED TEST SUITE
Tests around the critical paths and the code most likely to regress, wired into CI so failures block broken merges.
HANDOVER RUNBOOK
A runbook that covers setup, deployments, environment variables, common failure modes, and the fastest checks to run when something looks off.
Pricing
These are typical starting points for custom software development. I’ll confirm the right tier after discovery, once the technical brief and milestones are defined.
Priced items
Getting started
If you want me to hold time for this release, the next step is signing and booking the start date.
1. Sign this proposal to confirm scope and timeline. 2. Pay the 30% booking invoice to reserve the slot. 3. Send access to the repo, environments, and backlog so I can start discovery.
Signature
Fee summary
What stack are you going to build this in, and why?
I’ll propose a stack during discovery based on what you already have, who will maintain it after me, and the risks in your timeline. If you have a preference, I’ll work within it and call out the trade-offs in writing.
WHO OWNS THE CODE AND DO WE GET THE REPO ON DAY ONE?
You own the code. You get the repo on day one, and you’ll keep access throughout. I’ll work in your GitHub or GitLab if you have one, or I can set it up in yours at the start.
HOW DO YOU HANDLE CHANGES ONCE WE START AND SOMETHING NEW COMES UP?
I treat changes as swaps unless you tell me you want to expand scope. If a new item comes in, I’ll show what it replaces, what it delays, and any new risk it introduces, then you choose what moves.
WHAT DOES “DONE” MEAN FOR YOU: TESTS, DOCS, DEPLOYMENT, MONITORING?
Done means it runs in the target environment, matches the acceptance checks, and is safe to change. That includes tests where breakage is likely, setup and deployment docs, and basic monitoring so failures show up quickly.
Payment
To book the work, I invoice 30% when you sign the proposal. I invoice the remaining 70% when the finished work is handed over. Each invoice is due within 14 days.
Changes. I track changes against the backlog and milestones. If something new comes in, I’ll show what it replaces, what it delays, and any new risk. If you expand scope, I’ll price it before I start.
Your inputs. I’ll need a single point of contact for decisions, plus timely access to the repo, environments, and third-party accounts. If access or answers stall for more than a week, I’ll pause the schedule until they’re unblocked.
Ownership. You own the code and the work I write for you. You’ll have repo access from day one and keep it throughout. I can work in your GitHub or GitLab, or set one up in your account at the start.
Acceptance
Before I start building, I’ll write acceptance checks tied to the backlog items and the target environment. Work is done when it meets those checks, deploys successfully, and has the agreed tests and runbook updates.
Security and data. I’ll only ask for access I need to ship the work, and I’ll use your password manager or secure sharing. If I need production data to debug, I’ll ask first and prefer anonymised exports where possible.
Warranty fixes. For 14 days after handover, I’ll fix defects that are caused by the shipped changes at no charge. Changes in requirements, third-party outages, and new feature requests are handled as new work.
