Article
Forward deployed engineers vs. staff augmentation vs. project outsourcing
Three common ways to bring in outside engineering help, what each one is good at, and the questions that tell you which fits your situation.
Technology & resources
Technology chosen for your problem.
How we think about the layers of a software system, how we choose tools for each one, and the resources we've published so far.
Where the work happens in a software system
Most problems touch several of these layers at once. Thinking about them separately helps us find where a problem lives, and which part of a system needs to change.
- L1
Frontend
The interfaces people use: screens, forms, dashboards and the states in between.
Questions we ask
- Can everyone use it, including with a keyboard or a screen reader?
- How does it behave on a slow connection or a small screen?
- L2
Integrations
Connections between your software and third-party platforms.
Questions we ask
- What happens when the other system is slow, down or changes its API?
- Who owns each piece of data as it moves?
- L3
Backend & APIs
Services, business rules and the APIs other systems call.
Questions we ask
- Is every input validated before it's trusted?
- When something fails, will the logs say why?
- L4
AI & language models
Connecting existing AI models to products and workflows.
Questions we ask
- Which data may the model see, and for which users?
- How will we know the output is good enough before people rely on it?
- L5
Data & storage
Where information lives and how it moves between components.
Questions we ask
- Does the data model match how the business talks about its work?
- Can the schema change without taking the product offline?
- L6
Cloud & infrastructure
Where software runs, how it's deployed, and how it's configured safely.
Questions we ask
- Can we deploy the same way every time?
- Where do secrets live, and who can read them?
Across every layer
R1
Automation & developer tooling
Removing repetitive work, for operations teams and for engineers.
- Which manual step would hurt most if someone forgot it?
R2
Testing & reliability
Knowing that software works, and finding out quickly when it doesn't.
- Which tests would catch the failure that matters most?
- How would we find out about a problem before users do?
What exists today, and what we can build with you
Available now
We haven't published any tools, templates or open-source projects yet. When we do, they'll appear here. For now, our articles are listed below.
3 articlesBrowse the resource list
Built on request
These are engagement areas, not off-the-shelf products. Each one is built for your systems and conventions.
Specialist area: scope confirmed case by case.
Seven questions before we pick a tool
Technology choices outlast the project that made them. These are the questions we work through with you before committing to one.
- 01
Business requirements
What does the solution need to do, for whom, and how will we know it works?
- 02
Existing infrastructure
What do you already run, and can we build on it instead of adding something new?
- 03
Reliability and maintainability
Will this still be easy to run and change in two years, by someone who didn't build it?
- 04
Security and data handling
What data is involved, who may access it, and what rules apply to it?
- 05
Integration complexity
How many systems does it touch, and how well documented are they?
- 06
Team familiarity
Can your team support this after handover, or does it need skills you don't have?
- 07
Delivery constraints
What do the timeline, budget and future plans allow?
Resources
Today this is our published articles. Guides and other material will be added as they're written, never as placeholders.
- Article
What is a forward deployed engineer?
A plain-language explanation of what a forward deployed engineer does, where the role came from, and when the model is a good fit.
- Article
Understand the problem before you build the solution
Why discovery comes before building, and a simple framework for turning a vague pain point into a problem worth solving.
Working through a technical decision?
Tell us about the requirement, integration or engineering challenge. We'll share how we'd approach it.
What happens next
- 1
We read your message and reply, often with a few questions.
- 2
If it looks like a fit, we suggest a call to understand the context.
- 3
We follow up with how we'd approach it.