Approach

Method, made visible.

The six stages every project goes through, how a delivery week runs and the engineering standards behind every release, so you know exactly what working with METHODSS looks like before you start.

Working commitments

Four promises, on every project.

  1. Senior people only

    The people in the first call are the people who do the work.

  2. A working demo every week

    Progress you can click through, not a status report.

  3. You own the code and IP

    Repositories, designs and accounts are yours from day one.

  4. A reply from an engineer

    Every enquiry is read by an engineer and answered within one business day.

The workflow

Six stages, from first conversation to production.

Every project follows the same path, scaled to its size. Choose a stage to see what happens in it, what we need from you, and what you get at the end.

Stage 01 · Understand

We learn the business before we touch the brief.

  • Interviews and workshops with stakeholders and the people who will use the product
  • Review of existing systems, data, integrations and constraints
  • Goals, success measures and risks written down and agreed
Your part

Two or three workshops, and access to the people and systems involved.

You receive
  • Product brief
  • Success measures
  • Risk register
  • Technical audit

Who’s involved: Delivery lead, Product designer, Tech lead

discovery/brief.mdIllustrative
Goals
  • Approve supplier invoices in one place
  • Remove re-keying between CRM and ERP
  • Month-end close two days sooner
People we spoke to
Finance leadAP clerksOps managerIT
Risks
  • ERP API rate limitsHigh
  • Supplier data qualityMedium

Week to week

How a typical week runs.

We work in two-week sprints. You see working software every week, get a written update every day, and never have to chase anyone for status.

  • Daily updateMon–FriA short written update in your channel: done, next, blocked.
  • PlanningMonPriorities confirmed; sprint planning every second Monday.
  • Design & engineeringTue–ThuReviewed, tested changes land on staging as they are finished.
  • Live demoThuWorking software, not slides. Feedback goes straight onto the board.
  • Weekly summaryFriProgress, next steps, risks and decisions we need from you.

Engineering standards

The standards behind every release.

Ten working practices every project follows, from the first workshop to long after launch. Habits we can show you in the code and on the board, not badges or certifications.

  1. 01Plan

    Requirements & planning

    Nothing is built without a written brief and agreed measures of success.

    • User stories with acceptance criteria
    • Estimates list their assumptions and risks
    • Scope changes are discussed and recorded, never absorbed silently
  2. 02Plan

    Agile delivery & project management

    Short cycles and progress you can see without asking.

    • Two-week sprints, a working demo every week
    • One shared board for the whole team, including you
    • A written weekly summary with risks and open decisions
  3. 03Design

    UI/UX & product design

    Designs are tested with users before they are built.

    • Clickable prototypes reviewed with real users
    • One design system shared by design and code
    • WCAG 2.2 AA as the accessibility baseline
  4. 04Design

    Architecture & scalability

    Start simple, and leave room to grow.

    • Key decisions written down as architecture decision records
    • Well-supported technology your team can hire for
    • Expected load defined and tested before launch
  5. 05Build

    Code quality & maintainability

    Code is written for the next person who has to change it.

    • Every change reviewed by a second engineer
    • Strict typing, linting and formatting enforced in CI
    • Documentation updated in the same change as the code
  6. 06Build

    AI quality

    AI features are evaluated like any other code, before and after release.

    • Evaluation sets built from your real examples
    • Guardrails and human approval where mistakes are costly
    • Quality, cost and latency tracked in production
  7. 07Ship

    Testing & quality assurance

    Automated tests from the first sprint, not the last.

    • Unit, integration and end-to-end tests run on every change
    • Accessibility and performance checks on key journeys
    • Acceptance testing on staging before every release
  8. 08Ship

    Security & reliability

    Security is part of the definition of done.

    • Least-privilege access; secrets kept out of code
    • Dependency and vulnerability scanning in CI
    • Changes reviewed against the OWASP Top 10; backups and restores tested
  9. 09Ship

    Deployment & delivery

    Releases are routine, not events.

    • Automated CI/CD pipelines and infrastructure as code
    • Staged rollouts with a rehearsed rollback plan
    • Monitoring and alerts in place before launch day
  10. 10Run

    Continuous improvement & maintenance

    Launch is where real usage starts teaching us.

    • Analytics and error tracking from the first release
    • Regular dependency updates and maintenance windows
    • Runbooks and handover documentation kept current

Working with us · Questions

Questions, answered.

Something else on your mind? An engineer replies within one business day.

Ask an engineer

Most in the first two stages: a few workshops and quick answers while we learn the business. During the build, plan on a weekly demo of about 30–45 minutes plus feedback on the board. One person on your side who can make decisions makes the biggest difference.

They usually do, and that’s fine. Changes go onto the board, we explain the impact on time and cost, and you decide. Nothing changes scope or budget without your agreement in writing.

From the plan, not from a rate card. Each estimate lists the team, timeline, assumptions and the risks that could move it. Most clients start with a fixed-scope first phase, so cost and outcome are agreed before larger commitments.

Yes. We can work in your repositories, tools and rituals, pair with your engineers, or build a team your people gradually take over. Code review and documentation make that handover straightforward.

You do, from the first day. Code lives in your repository, designs in your workspace and infrastructure in your cloud accounts.

Start a project

See how this would work for your project.

Tell us what you’re building and where you’re stuck. A senior engineer will reply within one business day with honest questions and a suggested first step.

What happens next

  1. 01We review your briefAn engineer reads every message and replies within one business day.
  2. 02Discovery callAbout 30–45 minutes on your goals, constraints and what a good outcome looks like.
  3. 03Written proposalScope, approach, team, timeline and an estimate. No charge and no obligation.