How we deliver.
What you see each week, what a change costs and what you own, from scoping to support.
What we commit to.
- A demo of working software, every week.
- A budget report against the estimate, every week.
- Every change priced in writing before work starts.
- Code, cloud accounts and docs in your name from day one.
A week with us.
The same rhythm every week, so you always know what was built and what it cost.
How the money works.
We work on time and materials against a written estimate. The weekly budget report shows spend against that estimate, and any change is priced in writing before the work starts.
- Every week we send a budget report: spend to date against the written estimate in your statement of work.
- When scope changes, we price the change in writing, with its impact on timing, before work starts.
- You decide what happens next: go ahead, drop something else to make room, or leave it for later.
- Work outside the agreed scope does not start until you have seen that impact in writing.
- Where a piece of work is tightly defined, we can agree a fixed price for it.
From scoping to support, stage by stage.
Each stage sets out what happens, what you see and who is involved.
Scoping
We agree what is being built, what is left out and what it is estimated to cost, and write it into a statement of work.What happens
- You send your brief, RFP or a plain description of the problem. We read it before we speak.
- We talk through the constraints: the systems it has to work with, fixed dates, who is involved on your side and what has to be true at launch.
- We write down what is in scope, what is out of scope and the assumptions the estimate rests on.
- The statement of work records scope, the written estimate, team, start date and the post-launch support window.
What you see
- A written statement of work: scope, estimate, team and start date.
- The assumptions and exclusions behind the estimate, in writing.
- The post-launch support window, agreed for your project and written into the statement of work.
Who is involved
Marcos Hardy, CEO and engineering lead, leads scoping and answers the engineering questions. Anthony Hardy, CTO, covers the project plan and timeline, security and cloud infrastructure. From your side, the person who owns the outcome and the person who holds the budget.
Team and responsibilities
Before the start date you know who is on the team, who decides what and what we need from you.What happens
- The statement of work names the team and the start date.
- We write down the boundary: what we are accountable for, what stays with you and what belongs to other suppliers or teams.
- Inside a larger programme, you keep the programme and the roadmap. We take a defined workload and answer for it alongside your own engineers.
- Repositories, cloud accounts, domains and documentation are yours from day one.
What you see
- The named team and start date in your statement of work.
- A written split of responsibilities: ours, yours and anyone else's.
- Access to the repository from day one, because it is yours.
Who is involved
Marcos Hardy, CEO and engineering lead, is responsible for the engineering and for what gets built each week. Anthony Hardy, CTO, is responsible for the project plan and timeline, security and cloud infrastructure. From your side, one person who can set priorities and accept work.
Progress reviews
Every week we hold a progress review with you and demo working software.What happens
- The week starts with a plan: what we intend to finish, in priority order.
- Once a week we hold a progress review with you. It includes a demo of working software, so you see the thing itself running.
- We go through what was finished, what was not and why, and what comes next.
- We raise the risks we can see and the decisions we need from you.
What you see
- A demo of working software every week.
- What was finished, what slipped and what is planned next.
- The decisions we need from you and the risks we are watching.
Who is involved
Marcos Hardy, CEO and engineering lead, leads the review and the demo. Anthony Hardy, CTO, reviews the project plan and timeline. From your side, the person who sets priorities, plus anyone who wants to see the demo.
Budget and change control
We work on time and materials against a written estimate. The weekly budget report shows spend against that estimate, and any change is priced in writing before the work starts.What happens
- Every week we send a budget report: spend to date against the written estimate in your statement of work.
- When scope changes, we price the change in writing, with its impact on timing, before work starts.
- You decide what happens next: go ahead, drop something else to make room, or leave it for later.
- Work outside the agreed scope does not start until you have seen that impact in writing.
- Where a piece of work is tightly defined, we can agree a fixed price for it.
What you see
- A weekly budget report: spend against the written estimate.
- A written change impact, covering budget and timing, before work on the change starts.
Who is involved
Marcos Hardy, CEO and engineering lead, covers what a change means for the work being built. Anthony Hardy, CTO, covers what it means for the project plan and timeline. From your side, whoever holds the budget and can approve a change.
Quality assurance
This is how we work on our own product, Popup Pal, and it is our default on client work. Where your team already has standards and tooling, we work to those.What happens
- On Popup Pal, automated checks run on every pull request: lint, unit tests, integration tests against a real Postgres database, a dependency audit and a production build.
- TypeScript runs in strict mode, so type errors are caught before the code runs.
- Changes go to a separate staging environment first, with its own database and test payment credentials. Browser tests for payments, permissions, scheduled jobs and webhooks run against staging. They run separately from the pull request checks.
- The written rule in the Popup Pal repository is that production changes only through a reviewed pull request from the staging branch.
What you see
- The result of the automated checks on each pull request, in your repository.
- A staging environment where changes can be tried before release.
- The pull request history: what changed and when.
Who is involved
Marcos Hardy, CEO and engineering lead, leads the engineering. Anthony Hardy, CTO, is responsible for security and cloud infrastructure. Your own QA or release team, where you have one.
Launch
Go-live is planned with you in advance and goes out to accounts you already own.What happens
- We agree with you what has to be true before go-live and write it down as a checklist.
- The release goes to cloud accounts and domains that are already yours, so no account or domain transfer follows launch.
- Popup Pal has error monitoring and health check endpoints built in. That is our default on client work, unless your operations team already covers it.
- The post-launch support window agreed in your statement of work begins.
What you see
- A go-live checklist agreed before launch.
- The software running in your own cloud accounts, on your own domains.
Who is involved
Marcos Hardy, CEO and engineering lead, leads the release. Anthony Hardy, CTO, is responsible for infrastructure and security. From your side, the person who signs off the release and whoever runs your infrastructure.
Handover
Handover is documented. The repositories, cloud accounts, domains and documentation have been yours since day one, so what is left to hand over is knowledge.What happens
- We write a handover document covering how the system is put together, how to run it, how to release it and where everything lives.
- We bring the project documentation up to date. It has been yours since day one.
- We go through the handover document with whoever looks after the system next, your own team or another supplier.
- We review with you who has access to repositories, cloud accounts and domains, including our own access.
What you see
- A written handover document.
- Up-to-date project documentation, which you already own.
- Repositories, cloud accounts and domains that you own, as you have since day one.
Who is involved
Marcos Hardy, CEO and engineering lead, leads the handover of the engineering work. Anthony Hardy, CTO, covers security and cloud infrastructure. From your side, the engineers or supplier who take the system on.
Support
The post-launch support window is agreed for each project and written into the statement of work. After it, an ongoing engineering arrangement is available if you want one.What happens
- The support window is agreed during scoping, so you know what follows launch before the build starts.
- We do not publish a standard number of support days. The window is set for your project.
- When the window ends you choose. Your team takes the system on using the handover document, or we continue under an ongoing engineering arrangement.
- Ongoing product engineering is one of our three services. Footbao is the example: we have worked on its iOS and Android app and its backend continuously since August 2025.
What you see
- The support window written into your statement of work.
- The option of an ongoing engineering arrangement when the window ends.
Who is involved
Marcos Hardy, CEO and engineering lead, leads the engineering during the support window and under any ongoing arrangement. Anthony Hardy, CTO, remains responsible for security and cloud infrastructure.
From first message to statement of work.
What happens after you write, who you speak to and what you receive.
You send a short brief
Fill in the project sheet, or write to marcos@codehardy.com. A few paragraphs is enough: what needs building or changing, the systems it touches, any fixed date and who is involved on your side. If you already have a brief or an RFP, send that instead.
Who: You. Your message goes to Marcos Hardy, CEO and engineering lead.
We reply
We read what you sent and reply by email within one working day. If the work is not a fit for us, we say so in that reply. Otherwise we suggest times for a first call and tell you if there is anything useful to send beforehand.
Who: Marcos Hardy, CEO and engineering lead, who receives enquiries.
A first call with Marcos or Anthony
You speak to one of the two people who lead the company. Bring the brief, any deadline or budget limit you are working to, a picture of the systems involved and the names of the people who will take part in the decision. You leave with our view on whether we are a suitable supplier for this work, the questions that need answering before it can be estimated, and the next step.
Who: Marcos Hardy, CEO and engineering lead, for scoping and engineering questions. Anthony Hardy, CTO, for the project plan and timeline, security and cloud infrastructure.
A written proposal and statement of work
We send a written proposal and statement of work. It sets out scope, estimate, team and start date, and it records the post-launch support window. We work on time and materials against that written estimate. Where a piece of work is tightly defined, we can agree a fixed price for it. From the start date the repositories, cloud accounts, domains and documentation are yours, and the weekly progress review and weekly budget report begin.
Who: Marcos Hardy, CEO and engineering lead, for scope and engineering. Anthony Hardy, CTO, for the project plan and timeline, security and cloud infrastructure.
Send us the brief.
A few paragraphs is enough. We reply to enquiries within one working day.