Build the road once, then everybody drives on it.
Internal platforms, shared libraries and paved paths that make the correct way to do something also the easiest way. It is the discipline behind Sill, and we build it for other people's teams too.
- Paved path
- the easy way is the right way
- Shared
- one fix reaches every service
- Self-serve
- no ticket to start a project
Who this is for
You probably need this if…
01
Every team solves the same problem
Four services, four different approaches to logging, and nobody able to trace a single request across more than one of them.
02
Starting a project takes two weeks
Before a line of product code exists, somebody sets up CI, secrets, deployment and monitoring from scratch again.
03
Only one person can deploy
There is a way to ship and it lives in one engineer's head. Their annual leave is a company-level risk nobody has written down.
What this covers
The work, in detail.
7 capabilities
01
Internal developer platforms
One consistent way to create, deploy and observe a service, so a new project starts in an afternoon rather than over a fortnight.
02
Shared libraries
Authentication, logging, configuration and error handling written once and consumed everywhere, with versioning that respects your teams' release cycles.
03
Paved paths
An opinionated default route through the stack. Teams can step off it, but stepping off should be a decision rather than an accident.
04
Service scaffolding
Templates that generate a new service already wired for CI, observability, secrets and deployment on the first commit.
05
Environment management
Preview, staging and production defined identically in code, so a bug can never be explained away as an environment difference.
06
Developer experience
Measuring how long it takes to get from commit to production, and then deliberately shortening it rather than hoping it improves.
07
Platform documentation
Written for somebody joining next month, and kept current because it lives next to the code that it describes.
How we approach it
Positions we actually hold.
Opinions cost something to have. These are the ones we would argue for on your project, including where they make the work slower.
01
The easy path and the correct path are the same path
Standards enforced by documentation get ignored. Standards built into the scaffolding get followed without anybody having to try.
02
Platform teams serve, they do not gate
A platform that becomes an approval queue is worse than no platform at all. Self-serve, or your teams will quietly route around it.
03
One fix, everywhere
Shared infrastructure means a security patch lands in every service at once, rather than in whichever ones somebody remembered to update.
04
Measure commit-to-production time
It is the single number that tells you whether the platform is helping. If it is not falling, something in the design is wrong.
Technology
What we work with.
Defaults, not requirements. If you already run something else and have a team who knows it, we work in yours.
- Foundations
- Shared TypeScript libraries, monorepo tooling
- Scaffolding
- Service templates, generators, versioned defaults
- Environments
- Terraform, SST, preview deployments
- Observability
- OpenTelemetry defaults, structured logging by convention
Where this shows up in delivery
- Sill is this discipline applied in practice: one foundation, hardened in production, improved for every project at once.
- A fix we make to the permissions layer reaches every engagement on the platform, including work that shipped last year.
- We build the same pattern for client teams running several products who keep solving the same problems separately.
Bought as part of
This practice is never sold on its own. It is quoted inside one of the engagements above, as part of a single number.
Proof
Where we have actually done this.
Projects we designed, shipped and wrote up. Each one names the decision that was genuinely hard to get right.
Questions
What people ask about platform engineering.
- Is this only worth it for large engineering teams?
- It starts paying off at roughly three teams or four services. Below that the coordination cost is higher than the saving, and we will tell you that rather than sell it anyway.
- Will this slow our teams down?
- Only if it becomes a gate. We build platforms that teams opt into because they are faster, not ones they are required to use by policy.
- What if our teams use different languages?
- Then the platform covers deployment, observability and environments rather than shared code. A paved path does not have to mean a single stack.
- Do you run it afterwards?
- You can, and the documentation is written with that in mind. A retainer is available where you would rather we kept it current instead.
Related reading
Written on this, by us.
Cloud & Security · 7 min read
Your Cloud Bill Went Up Forty Per Cent and Nobody Knows Why
Cloud spend rarely grows because of one decision. It grows because of a dozen small ones nobody wrote down. Here is how to find them, in order of how much they are costing you.
How We Work · 6 min read
Why We Quote Four Weeks When Everyone Else Says Three Months
It isn't that we work faster or cut corners. Most of a software quote is rebuilding plumbing that has nothing to do with your business. Here's the actual arithmetic.
Engineering · 8 min read
Why Your Agency's Tech Stack Shouldn't Be Yours by Default
Every firm has a preferred stack and most of the reasons are honest. How to tell when the preference is serving your project and when it is serving theirs.
Usually combined with
All practice areas →Tell us what you’re trying to build.
Describe the problem in your own words. We’ll come back within one business day with a scope, a number and a date.
Phone
+1 (407) 796-2376Reply time
One business day, from an engineer
Based in
Orlando, Florida · serving the United States
What happens next
- A reply within one business day, from an engineer
- A thirty-minute call, with no qualifying call before it
- A written scope and a fixed number, if it fits