Skip to content
CodeHardy

How we deliver.

Work directly with the people leading your project. See progress every week, keep track of spending and own the result.

Know who is leading the work.

Marcos Hardy

Our CEO and engineering lead turns the requirements into working software. He leads the build and your weekly demo.

Anthony Hardy

Our CTO is responsible for the project plan, timeline, security and cloud infrastructure.

A week with us.

A demo and a budget update each week keep you close to the work.

  1. The work

    We build the agreed features, integrations and improvements.

    You see: The code in your own repository.

  2. The demo

    We show you working software and review progress together.

    You see: What is ready, what needs attention and what comes next.

  3. The budget

    We report spending against the written estimate.

    You see: A weekly record of what has been spent.

  4. When plans change

    We explain the cost and timing before starting the extra work.

    You see: The impact of a change in writing.

Clear costs as the project develops.

We charge for time spent against a written estimate. Tightly defined projects can also be agreed at a fixed price.

  • You receive a weekly report showing spend against the estimate.
  • Before we start a scope change, we send its cost and impact on timing in writing.
  • The commercial terms and support arrangements are agreed before work begins.

From the first brief to launch.

The practical details, including testing, handover and support after the product goes live.

  1. Agree the work

    Start with the problem, the systems involved and what a useful first release needs to do.

    What happens

    • We discuss your brief, deadlines, budget and technical constraints.
    • We agree what to build and put the scope, estimate and responsibilities in writing.
    • We agree support after launch before the project starts.

    What you see

    • A written scope and estimate.
    • The proposed team, start date and support arrangements.

    Who is involved

    Marcos leads the engineering discussion. Anthony covers the project plan, security and cloud infrastructure. You bring the business priorities and budget.

  2. Set up the project

    Know who is doing the work and keep ownership of the code and accounts from day one.

    What happens

    • We agree who is responsible for each part of the project, including any work involving your team or other suppliers.
    • Your repositories, cloud accounts, domains and documentation belong to you from the start.

    What you see

    • Named people and clear responsibilities.
    • Access to your code and project accounts.

    Who is involved

    Marcos leads engineering. Anthony owns the project plan, security and cloud infrastructure. Your project lead sets priorities on your side.

  3. Build and review

    See working software every week and discuss what comes next.

    What happens

    • We demo what has been built and explain anything that has changed or needs a decision.
    • We review progress with you and discuss the next priorities.

    What you see

    • A weekly demo of working software.
    • Progress, outstanding decisions and the next work to tackle.

    Who is involved

    Marcos leads the demo. Your product or project lead brings feedback and priorities. Anthony is responsible for the project plan and timeline.

  4. Manage the budget

    We charge for time spent against a written estimate. Tightly defined projects can also be agreed at a fixed price.

    What happens

    • You receive a weekly report showing spend against the estimate.
    • Before we start a scope change, we send its cost and impact on timing in writing.
    • The commercial terms and support arrangements are agreed before work begins.

    What you see

    • Weekly spend against the estimate.
    • The cost and timing of changes before the work starts.

    Who is involved

    Marcos explains the engineering involved in a change. Anthony covers the project plan and timing. Your budget holder reviews the cost.

  5. Test before release

    The checks depend on the product and your existing standards. Our own product, Popup Pal, shows the approach in practice.

    What happens

    • On Popup Pal, pull requests run automated checks, unit and integration tests, a dependency audit and a production build.
    • Changes run in a separate staging environment, where browser tests cover payments, permissions and background processes.
    • The repository's release procedure requires a reviewed pull request before production changes.

    What you see

    • Your project's testing and release approach agreed during scoping.
    • Access to the code and its check results.

    Who is involved

    Marcos leads engineering. Anthony covers security and cloud infrastructure. Where you have a QA or release team, they are part of the discussion.

  6. Go live

    Deploy into your accounts and begin the support agreed for your project.

    What happens

    • We plan the release with your team, including any systems or suppliers it depends on.
    • The product goes live in accounts you own, with the agreed post-launch support in place.

    What you see

    • The product running in production.
    • Clear support arrangements for the period after launch.

    Who is involved

    Marcos leads the release. Anthony covers infrastructure and security, alongside whoever approves and supports releases on your side.

  7. Hand over the work

    Your team receives the documentation it needs to take the work on.

    What happens

    • We document the handover for the people who will look after the software.
    • The code, cloud accounts, domains and documentation remain yours, whether we continue working together or not.

    What you see

    • A documented handover.
    • Continued ownership of the code, accounts and documentation.

    Who is involved

    Marcos handles the engineering handover. Anthony covers security and cloud infrastructure. Your engineers or next supplier receive the work.

  8. Support and improve

    Agree support for the launch, then decide whether you need continued engineering help.

    What happens

    • The post-launch support period is set out in your project agreement.
    • After that, you can continue with us for new features, fixes and improvements, or take the work in-house.

    What you see

    • An agreed support period.
    • An option to continue with ongoing product engineering.

    Who is involved

    Marcos leads ongoing engineering, with Anthony responsible for security and cloud infrastructure.

How to get started.

An initial conversation helps us understand the work and whether we are the right people to deliver it.

  1. Tell us about the project

    A few sentences about what you need are enough to start. Use the form or email marcos@codehardy.com. If you have a brief or RFP, send it over.

    Who: Your message goes to Marcos Hardy, CEO and engineering lead.

  2. Hear back from us

    We reply to enquiries within one working day. We will let you know whether the project looks like a fit and arrange a conversation if it does.

    Who: Marcos reads and replies to enquiries.

  3. Talk through the work

    Speak with Marcos or Anthony about the problem, your constraints and what you want to achieve. We discuss what needs answering before we can estimate the work and agree the next step.

    Who: Marcos covers engineering. Anthony covers the project plan, security and cloud infrastructure.

  4. Review the proposal

    Once the requirements are clear, we put the scope, estimate, team and start date in writing. The proposal also sets out the commercial terms and support after launch, so you can decide whether to proceed.

    Who: Marcos and Anthony prepare the proposal around your project.

Tell us what you have in mind.

An idea, a problem or an existing brief. We reply to enquiries within one working day.