Understand the business. Then pick the architecture.
A full pass over the infrastructure, and a longer conversation about where the product is going. The technical solution gets worked backwards from that. Never forwards from whatever happens to be installed.
$ ls ./accelerators →Observability and one pipeline, started early.
Where the monitoring, the logging, or a shared CI/CD platform is missing, it starts early — these are the slowest things in an estate to mature. Where you already have them, we use yours. Either way, everything after this lands on real signals instead of guesses.
$ ./why --one-platform
One platform is an opinion, held on purpose — two pipeline stacks means every fix lands twice and trust lands nowhere. Both start early for lead time, not urgency: a baseline has to accumulate before an anomaly reads as an anomaly, and a pipeline earns trust one real release at a time. Start them late and the maturity arrives after the moment you needed it.
The first pass is a draft. On purpose.
Write the IaC. Pilot a few services through it. The first pass does not have to be perfect — each service that moves surfaces a pattern, and the next pass hardens it.
read: the blocks these cycles produced →The code has to meet the platform halfway.
In between cycles, the codebase gets read for what must change to run on the new infrastructure — configuration, secrets, service discovery, the build itself. We do not write your application code. We do tell you exactly where it will fight the platform, before the weekend where that discovery is expensive.
$ ./why --read-the-code
A migration plan that has never read the code is a plan about infrastructure only — the surprises live in the other half: the connection string built at compile time, the secret checked into a config file, the health check that answers 200 while the app is still warming up. Finding those on a Tuesday costs a pull request. Finding them mid-cutover costs the weekend.
This sequence has run at scale.
In a role at a healthcare-AI company, Speko's founder led a cloud transformation across 45 applications and machine-learning models, with more than a petabyte of data behind them. The estate moved blue/green, a parallel estate built alongside the live one, and the first cutover succeeded: the sequence above, run before the date — signals accumulating for months, one platform everything shipped through, drafts already redrafted, the code read before it moved.
The rest of the record reads the same way — each number fixed to the one prior role it happened in. A biography, not Speko engagements; none of it is a promise about yours.
At a Series B — the Heroku-to-AWS migration, run end to end.
In another role — 40+ ECS microservices, multi-region, zero-downtime migrations.
In another — deployment time cut 60%.
In another — cloud costs cut 30–40%.
You cannot check any of this, and the site knows it. So the next migration is written down instead as conditions you can enforce — five of them, on the cutover page, yours to fire us on.
$ ./read --the-trade
That is the deal the whole site runs on: an unverifiable past converted into a verifiable present. A track record is a claim about what happened somewhere you were not; the five conditions are claims about what happens in your own accounts, in writing, while you watch. If the record above earns anything, it should earn the thirty minutes it takes to read them.
The owner is the principal architect. The delivery lead sets the standard.
Two people run this company. Spencer owns it and its architecture — the record above is his, kept to the roles it happened in. Martha holds delivery to a standard a steering committee can read without being walked through it. Neither card is the lesser one.
Spencer Kotowick
He owns this company and is its principal architect — the record above is his, and the sequence on this page is how he works, written down from what already worked. That record spans fintech, healthcare AI, POS and e-commerce, telehealth, and game software, with years inside an AWS Premier Partner consultancy in that biography too.
"Inside an AWS Premier Partner consultancy" is a line in a biography — a place he worked, not a badge this company holds. Speko claims no AWS partner status, here or anywhere on this site.
aws summit toronto 2022 · speaker read: the record above →Martha Tejeda Lopez
A programme and project manager across domains — any estate, any programme. Concurrent workstreams held to one plan, the sequencing, and the executive reporting a steering committee reads without being walked through it.
One application of that discipline — the cutover — is written down in full, in the open, where a client can hold it against us. It is hers to front because she does not inherit the standard — she sets it.
read: the discipline she fronts →