Skip to content
softlanceo

How we work

What it is actually like to work with us.

The opinions we hold, what happens week by week, and the three shapes an engagement takes. Including how each one ends, which is the question most sites avoid.

01/Principles

Five opinions, and what they cost us.

  1. We would rather ship a small thing that runs than a large thing that demos

    Software only starts teaching you anything once it is in front of real users on real infrastructure. A narrow version in production beats a broad version in staging, every time, and it is cheaper to be wrong about.

  2. The people who design the architecture should carry it

    Decisions made by someone who will never be woken up by them tend to be optimistic. We build and we operate, which changes what gets chosen — usually toward the boring option.

  3. Cost is a design constraint, not an invoice

    The running cost of an architecture is decided while it is being drawn, and it is nearly free to change at that point. We price the shape before we build it, so the first bill is not a discovery.

  4. If your team cannot change it, we have not finished

    Handover is not a document dump at the end. Your engineers make a real change to the pipeline and the code with us watching, and if they cannot, that is our problem to fix before we leave.

  5. We say when the answer is no

    Some migrations are not worth doing, some bills are already about right, and some rewrites should stay unwritten. Telling you that costs us work in the short term and is the only way the rest of our advice is worth anything.

02/The engagement

Six steps, start to finish.

Each one lists what happens, what we need from you, and what you have at the end of it. The last step is optional and we mean that.

  1. You tell us what you need

    You send the problem in whatever detail exists — a spec, a screenshot of a dashboard, or two paragraphs describing what keeps going wrong. We read it and reply ourselves.

    What you do
    Describe the problem, not the solution you think you need.
    What you get
    A reply from someone technical within one business day.

  2. We look at it properly

    A call, and where relevant read-only access to the code or the AWS account. We would rather spend an hour looking than an hour speculating, and it changes the answer often enough to be worth it.

    What you do
    Give us enough access to be useful, or tell us what we can see instead.
    What you get
    An informed opinion rather than a generic one.

  3. We propose an approach

    A written recommendation: what we would do, in what order, what it produces, roughly what it takes, and what we would deliberately leave alone. Including the parts we think are not worth doing.

    What you do
    Push back. The proposal is a draft until you have argued with it.
    What you get
    A scoped approach with the assumptions and exclusions written down.

  4. We build it in increments

    Work lands in small pieces, each deployed and visible. You see the real thing continuously instead of receiving a status report about it.

    What you do
    Look at it weekly and tell us what is wrong while it is cheap to change.
    What you get
    Working software in an environment you can use, updated as we go.

  5. We hand it over

    Documentation, a runbook, and a session where your engineers make a change themselves while we watch. Whatever is still unclear at that point gets fixed.

    What you do
    Put the person who will own it in the room.
    What you get
    A repository, a runbook, an architecture document and a recorded walkthrough.

  6. We keep it running, if you want that

    Monitoring, incident response, maintenance and continued improvement. Entirely optional, and never a condition of the work that came before it.

    What you do
    Decide. Either answer is a normal one.
    What you get
    A written support scope, or a clean exit with nothing owed.

03/Engagement models

Three ways this works, including how each one ends.

Shape only — no rates on a web page, because a rate without a scope is a number pretending to be information.

Fixed-scope project

Best for
A defined piece of work with a recognisable finish line — a migration, a security review, a first version of a product, a pipeline build.
How it is scoped
Scoped in writing before it starts, with the deliverables listed and the exclusions listed just as explicitly. Changes to scope are agreed and priced before they happen, not absorbed quietly.
How it is billed
A fixed price against that scope, billed on milestones tied to things you can see working rather than to dates on a plan.
How it ends
It ends when the deliverables are handed over and accepted. There is no automatic rollover into a retainer.

Dedicated team

Best for
Continuous product work where the scope keeps evolving, and you want engineering capacity that stays loaded into the context rather than relearning it each time.
How it is scoped
Scoped as capacity, not as a feature list. You get a set number of engineers for a set period, with priorities agreed at the start of each cycle and reprioritisable between them.
How it is billed
A monthly rate per engineer, agreed up front. The rate does not change mid-engagement, and unused capacity is not something we invent work to fill.
How it ends
A notice period agreed at the start, running both ways. Handover is part of the notice period rather than something arranged afterwards.

Advisory and support

Best for
Systems that are live and need watching, teams that want a second technical opinion before committing to something, or ongoing maintenance without a full-time team.
How it is scoped
A written scope covering what is monitored, what we change without asking, what needs your sign-off, and how you reach us outside working hours.
How it is billed
A monthly retainer sized to the scope, reviewed periodically against what the work actually turned out to be — in both directions.
How it ends
Monthly, with an agreed notice period. Everything needed to run the system without us is already in your hands throughout.

04/Communication

How a week actually runs.

One shared channel
A Slack or Teams channel with your team and ours in it. No account manager relaying messages, and no ticket queue standing between you and the person doing the work.
A queue you can see and reorder
Work lives in a shared issue tracker — yours if you have one. You can always see what is in progress, what is next, and what we have not got to.
Weekly, short
A weekly call against the running software rather than a slide. If there is nothing worth discussing that week we cancel it instead of filling it.
Written decisions
Anything architectural gets a short written record: what we chose, what we rejected, and why. It is how the reasoning survives someone leaving.
Your repositories, your accounts
Code goes in your organisation and infrastructure in your AWS account wherever possible. You should never need our permission to access your own systems.

05/Stack

What we build and operate with.

If your problem needs something that is not on this list, we will tell you rather than bend it to fit.

Languages
  • TypeScript
  • JavaScript
  • Python
  • SQL
Frontend
  • React
  • Next.js
  • Tailwind CSS
Backend
  • Node.js
  • FastAPI
  • Django
  • REST
  • GraphQL
AWS compute
  • Lambda
  • ECS
  • Fargate
  • EKS
  • EC2
  • API Gateway
AWS data
  • RDS
  • Aurora
  • PostgreSQL
  • DynamoDB
  • S3
  • ElastiCache
AWS platform
  • VPC
  • CloudFront
  • Route 53
  • IAM
  • CloudWatch
  • EventBridge
DevOps
  • Docker
  • GitHub Actions
  • AWS CDK
  • Terraform
  • CloudFormation
Testing
  • Vitest
  • Jest
  • Playwright
  • pytest

06/Questions

Working together, asked about.

01

Do you work fixed-price or time-based?

Both, depending on the shape of the work. Defined projects with a clear finish line suit a fixed price; continuous product work and support suit a monthly arrangement. We will recommend which fits and explain the trade-off rather than defaulting to whichever suits us.

02

How small a piece of work will you take?

Small enough that a review, a broken pipeline or a single integration is worth asking about. If a piece of work is too small to be worth engaging us for, we will usually just tell you how to do it.

03

Can you work alongside our existing engineering team?

Yes, and it is common. Work goes through your repository and your review process, sequenced so we are not competing over the same files. Your team stays in control of what gets merged.

04

What if we want to stop?

Fixed-scope work ends at the deliverables. Ongoing arrangements have a notice period agreed at the start, running both ways. Because handover material exists throughout, stopping does not require a separate exit project.

Start with the problem.

No discovery funnel and no gated PDF. Send a few lines and an engineer will reply within one business day.

Start a project