DEV Community: Michael Masterson

The Truth About Serverless APIs Nobody Mentions

Michael Masterson — Thu, 14 May 2026 19:11:23 +0000

I've noticed serverless conversations tend to split into two camps:

People who think it solves everything, and people who think it's a mistake.

The reality is much more useful than either extreme.

Everyone who sells you on serverless leads with the same three points: no servers to manage, automatic scaling, and you only pay for what you use.

All of that is technically true.

None of it is the whole story.

I've shipped serverless APIs in production — Go Lambdas behind API Gateway, the kind that power real user-facing products. I'm not here to talk you out of it. For the right workload, it's genuinely excellent.

But the gaps between the pitch and the reality are specific, and knowing them in advance changes the decisions you make early, when they're still cheap to change.

Cold starts are real — just not how you think

Lambda cold starts happen when AWS needs to provision a new execution environment for your function. The runtime boots, your init code runs, and then the handler executes.

For a Go function on arm64, that's typically 50–150ms total. For Node.js or Python with heavy dependencies, it can be 500ms–2 seconds.

The part nobody leads with: cold starts are probabilistic, not guaranteed.

Under steady traffic, most invocations hit warm instances. You'll rarely see them in your P50 or even P95. Where they show up is P99 and beyond — the tail latency your best users experience right after a traffic spike, or the first request after a quiet weekend.

The practical advice: profile in production with real traffic before you add Provisioned Concurrency. It costs money and adds complexity.

For most APIs, the smarter move is optimizing your init code:

lazy-load dependencies
keep your binary small
initialize only what the first request actually needs

Fix the actual problem before reaching for the expensive solution.

The billing math will surprise you

Lambda pricing is simple on paper: you pay per request and per GB-second of execution time.

At low traffic, it's nearly free.

The surprise comes at scale — or in specific usage patterns.

The scenario that bites teams most often: a Lambda that does meaningful work per invocation. Parsing a large payload, doing in-memory transformation, making multiple downstream calls.

These functions run longer, use more memory, and the cost per invocation adds up faster than the pricing page suggests.

A few numbers from real workloads:

A lightweight REST Lambda (Go, 128MB, 20ms avg): ~$0.40 per million requests
A heavier processing Lambda (Node, 512MB, 800ms avg): ~$8.00 per million requests

That 20× difference in cost per million requests adds up quickly when you have real traffic.

It's still cheap compared to running servers — but the assumption that serverless is always the low-cost option needs to be verified, not assumed.

API Gateway pricing is also frequently missed. At $3.50 per million requests for HTTP APIs, a high-traffic public endpoint can make Gateway cost more than the Lambda it fronts.

Know the full cost model before you commit.

Debugging is a different skill

Local development for Lambda is awkward.

You can simulate the execution environment with tools like AWS SAM or custom test harnesses, but you're never truly running the same thing that runs in production.

The gap shows up in exactly the moments you can least afford it.

Observability requires deliberate setup.

A Lambda that exits silently leaves no trace unless you've instrumented it. CloudWatch Logs are the floor, not the ceiling — you need structured logging, correlation IDs, and ideally X-Ray tracing before you're in production, not after something breaks.

The failure modes are also harder to reproduce.

A Cognito authorizer rejecting a token before your code runs looks different from your code returning a 401. A DynamoDB throttle on a hot partition looks different from a Lambda timeout.

Getting fast at debugging serverless systems means learning the AWS console deeply:

CloudWatch Insights queries
X-Ray service maps
reading IAM policy errors without a stack trace to guide you

Statelessness is a constraint, not just a pattern

Every Lambda invocation starts with a clean slate.

That's the feature — it's what makes horizontal scaling effortless.

It's also the constraint that eliminates entire categories of architectural approaches.

No in-memory caches that persist across requests. No background jobs that run between invocations. No WebSocket connections that stay open. No files written to disk that the next request can read.

If your application assumes any of those things, serverless isn't wrong — but it's not your foundation. It's a piece of a larger architecture that needs something else alongside it.

This comes up most often when teams decide mid-project that they suddenly need a feature requiring persistent state.

Adding ElastiCache or SQS to a serverless architecture is straightforward — but it's a different architecture than what you started with, and the integration work is non-trivial.

The most dangerous part is that many of these problems don't show up until the system already matters.

Vendor lock-in is real, and that's okay

A Lambda function isn't a Docker container.

It doesn't run the same way everywhere else.

Your Go binary targeting provided.al2023 on arm64 can technically run in other environments, but your API Gateway routes, Cognito authorizers, DynamoDB single-table design, and SES integration are AWS-specific throughout.

I'm not arguing against it — I use all of those services in production.

But it's worth being honest:

If you go deep on serverless AWS, migrating later means a substantial rewrite.

Make that decision deliberately, not by default.

When not to use it

Serverless is the wrong tool when:

You have persistent connections — WebSocket servers, gRPC streams, database connection pools
You have long-running jobs — Lambda has a 15-minute max timeout
You have very high, sustained concurrency — account-level concurrency limits can affect multiple services simultaneously
You need low and predictable latency at P99 — cold-start tail latency is difficult to eliminate completely

When it's the right call

Event-driven workloads.

APIs with bursty or unpredictable traffic.

Background processing triggered by S3 uploads, SQS messages, or DynamoDB streams.

Any workload where you don't want to manage capacity and the per-request cost model fits your traffic profile.

The API powering this site is Go Lambdas behind API Gateway.

Contact form submissions, resume requests, visitor analytics, admin dashboard — all of it.

It handles the traffic I need, costs less than $1/month to run, and I've never paged for a server that went down.

For that workload, it's the right call.

The key is understanding what you're actually trading.

Serverless isn't simpler than traditional infrastructure.

It's differently complex.

The operational burden shifts from server management to observability, IAM, and distributed system debugging.

That trade is absolutely worth it in the right context.

Go in with your eyes open, and it's one of the most productive architectures available.

The right architecture should help your team maintain momentum as the system grows — not create friction six months later.

At M²S² Engineering Group, we help teams make these decisions before they become expensive to unwind.

Originally published at m2s2.io

Structure Creates Power: Lessons from Wing Chun and Engineering

Michael Masterson — Fri, 08 May 2026 20:14:02 +0000

I recently started training Wing Chun.

At first glance, it doesn't look like what most people expect from martial arts. There's no flash. No wasted motion. No emphasis on brute force. Everything is controlled, direct, and intentional.

When I first walked into training, I expected to learn techniques—strikes, blocks, sequences.

Instead, we spent time on something much simpler.

Stance. Balance. Positioning.

It wasn't exciting. It didn't feel like progress. But it quickly became clear that everything depended on it.

In Wing Chun, there's a core idea that shows up in everything you do:

Structure creates power.

Economy of motion creates speed.

The more I train, the more I realize how closely this maps to building software.

Early on, speed feels easy.

You're building something new. Writing code, shipping features, making decisions quickly. It feels like momentum.

And in a way, it is—at least at the start.

But over time, something changes.

Small decisions begin to stack. Patterns drift. The system becomes harder to reason about. Bugs start showing up in places that used to feel simple. Every new change introduces a little more friction than the last.

You're still moving, but not forward.

You're spending more time fixing than building.

In Wing Chun, that breakdown is familiar.

If your structure isn't right, everything becomes harder under pressure. Movements get sloppy. Reactions slow down. Power disappears.

You can try to compensate with effort—but it doesn't hold up.

That's why so much time is spent on foundation.

Before anything complex, you focus on the basics:

where your weight sits
how your body is aligned
how you connect movement from one position to the next

It's not flashy. But it's what allows everything else to work.

Software isn't that different.

It's tempting to skip the foundation early on. To move quickly, defer decisions, and assume you'll clean things up later.

And for a while, that works.

But without a solid foundation, systems become fragile. Small changes carry risk. Complexity builds faster than expected. Eventually, the speed you thought you had starts working against you.

What's interesting is that Wing Chun isn't about doing more.

It's about doing less—but doing it well.

Every movement has a purpose. There's no extra motion. No wasted energy. If something doesn't directly contribute to the outcome, it's removed.

That idea carries over into engineering more than most people expect.

The best systems aren't the ones with the most flexibility or the most features. They're the ones where each piece has a clear role, and everything works together in a way that feels intentional.

Simple systems move faster—not because they do more, but because they do less with clarity.

Once the foundation is in place, something shifts.

In Wing Chun, movements become more consistent. Reactions become faster. Techniques that felt awkward start to flow naturally. You're not thinking as much—you're responding.

More complex combinations become possible, not because you've added more, but because everything underneath them is stable.

That's what a good foundation does in software.

It doesn't slow you down. It removes friction.

It gives you:

consistent patterns
clear boundaries
confidence in making changes

From there, you can move faster—not just once, but repeatedly.

You can build on top of what you've already created without constantly reworking it.

This is where the idea of Engineering Momentum really starts to make sense.

Most teams don't struggle because they lack the ability to build.

They struggle because the systems they build don't support continued progress.

Speed shows up early. But it doesn't last.

Bugs increase. Changes get harder. Teams spend more time stabilizing than creating.

Momentum breaks.

The teams that maintain momentum tend to do something different.

They don't avoid speed—but they don't chase it blindly either.

They make a few key decisions early:

establish structure
define patterns
create a foundation that can support growth

Not over-engineering. Not unnecessary complexity.

Just enough structure to keep things moving forward.

Wing Chun isn't about brute force.

It's about alignment, structure, and efficiency.

The power doesn't come from doing more—it comes from doing the right things, in the right way, with the right foundation underneath.

The same is true in software.

You don't need the most complex system.

You don't need the most flexible architecture.

You don't need to solve every problem up front.

You need a foundation that allows you to keep moving.

Structure creates power.

Simplicity creates speed.

And the right foundation creates momentum.

Originally published at m2s2.io

What I Do in the First 30 Days With a New Engineering Team

Michael Masterson — Mon, 04 May 2026 02:57:19 +0000

Most founders who bring in a fractional engineering leader are looking for the same thing: engineering momentum. Not activity — engineers are almost always busy — but directed motion. Work that compounds toward something, where effort today makes tomorrow's effort easier rather than harder.

When that's missing, the symptoms are familiar. Delivery has slowed. Cross-team communication feels like friction rather than collaboration. Something that should take a week takes a month, and nobody can quite explain why. The team seems capable, but the output doesn't reflect it.

What's usually underneath that isn't a talent problem. It's a system problem. And untangling it — in a way that actually sticks — takes more than a fresh set of eyes. It takes experience reading the specific signals that tell you what's actually happening versus what the visible problems are pointing at.

Here's what that process looks like in practice.

Week 1: Build the map

Before anything changes, I need to understand the system — and a software team is a system, not just a collection of people writing code. That means looking at the technical layer and the human layer simultaneously, because they almost always reflect each other.

I meet every engineer individually in the first week. One at a time, without an agenda beyond understanding their experience. What are they working on? What's making it harder than it should be? If they could change one thing, what would it be?

What surfaces in these conversations is irreplaceable. Engineers know where the complexity lives and why it got there. They know which decisions created the most downstream pain. They know who carries the most implicit knowledge and who is quietly stretched thin. They also know — and this comes up more than founders expect — when their team has drifted into operating in isolation. Processes that were never documented. Tooling built internally that solves problems nobody else in the organization knows they solved. Decisions made locally that have never been communicated upward or across to other teams.

That last pattern is one of the most common and most costly things I encounter. Teams develop their own ways of working — their own rhythms, their own standards, their own internal language — and those ways of working never make it out of the team. What starts as autonomy quietly becomes a silo. And silos make organizational communication slow, expensive, and fragile.

I also spend time in the code this week — reading commit history, tracing the architecture, understanding where complexity has clustered and why. A codebase reflects the culture that built it. The shape of the technical debt tells you something about how decisions were made and whether they were ever revisited. Undocumented patterns tell you what was understood but never written down. If you know how to read it, the codebase is one of the most honest documents in the organization.

By the end of week one I have a working map — of the people, the technical landscape, and the relationship between the two.

Week 2: Find the real constraints

Most teams that are underperforming aren't lacking talent. They're operating inside a set of structural constraints that create friction across nearly everything they do — and because the friction is everywhere, it feels like the natural cost of building software rather than something that can be addressed.

This week is about finding what those constraints actually are, specifically, for this team and this organization. I start showing up more visibly — in code reviews, architecture discussions, planning sessions — not to direct them yet, but to see how the work actually flows in practice.

The separation between symptoms and causes is where real diagnostic experience matters. Slow delivery, unclear priorities, duplicated effort, decisions that have to be relitigated every sprint — these are real, but they're downstream of something more specific. The skill isn't just knowing what patterns to look for. It's knowing which ones are causing the others, and in what sequence addressing them will create the most leverage.

One of the patterns I look for explicitly is what engineers sometimes call "not invented here" syndrome — the tendency for teams to build or develop their own version of something rather than adopt what already exists, either within the organization or in the broader ecosystem. It comes from a good instinct: engineers want to understand and own what they're building. But left unchecked, it compounds into a much larger problem. Each team's internal tooling, processes, and conventions become a private language. Cross-team collaboration requires translation. Organizational knowledge stays trapped inside individual teams rather than flowing across them. What should be a shared foundation becomes a collection of parallel, incompatible approaches — and the cost shows up as exactly the kind of slow, grinding friction that makes it feel like the whole organization is moving through water.

Addressing this isn't about standardizing everything into uniformity. It's about identifying what needs to be shared and building the bridges that let it be. That's a technical problem, an organizational problem, and a communication problem all at once — and untangling it requires understanding all three.

Team structure becomes concrete this week as well. Not headcount, but organization. Does ownership match accountability? Are there engineers operating above or below their actual level? Are there gaps a new hire would fill, or gaps that restructuring existing roles would address just as well? Scaling a team doesn't always mean growing it. Sometimes the leverage is in removing the structural friction that's preventing the people already there from doing their best work.

Week 3: Begin moving

The trust built in the first two weeks has to translate into visible change, or it dissipates. By week three the team is watching — not skeptically, but expectantly. They shared things with you. They want to see what you do with it.

I pick the highest-leverage change available and make it. Most often this is a process or communication change rather than a technical one — not because the technical work isn't important, but because process changes produce immediate, felt results. A clear definition of done eliminates the ongoing ambiguity about what "finished" means. A code review standard cuts the time spent waiting on feedback. A shared architecture decision record means that the decision made this week doesn't have to be made again in six months when the context has evaporated.

On the organizational communication side, this is often when I start building the connective tissue that was missing — shared documentation standards, cross-team visibility into technical decisions, communication patterns that let teams stay loosely coupled rather than accidentally isolated. None of this is glamorous. All of it matters.

The people conversations deepen this week as well. Role misalignments, skill gaps, or team dynamics that are creating drag get addressed directly — with honesty, with care, and with a clear picture of what a better outcome looks like. Engineers want to know where they stand. Most of the difficult conversations I've had with people on teams were hard because they'd been deferred, not because they were inherently bad news.

If there are hiring needs, I start building the case now — not as a headcount request, but as a specific capability tied to a specific outcome. What can this team not do today that it needs to do next quarter, and is there someone already here who could grow into it, or does that capability need to come from outside?

Week 4: Establish the next horizon

By week four the team should feel different — not because the fundamental work has changed, but because the structural friction around it has started to lift. Velocity isn't a metric. It's a quality of motion. A shared sense of direction and the confidence that comes from knowing what you're optimizing for.

I bring a clear picture to the founder or leadership team: the team's actual strengths, what was creating the most drag and what has been done about it, where the remaining gaps are, and what the people and organizational plan looks like going forward. Not a deck of observations — a grounded account of the current state, built from real understanding of the codebase, the team, and the business context they're operating in.

Then I define the next 60 days in terms the whole team can commit to. Real targets tied to actual capacity. Technical priorities sequenced against the team's current constraints rather than set against an idealized version of them. Organizational changes that are still in motion but have a clear destination.

The goal of the first month isn't transformation. It's foundation — the kind that makes transformation possible. A team that understands what it's building and why, with the communication patterns and shared standards to move as a unit rather than a collection of individuals, is a team that can build what actually moves the business forward.

That's engineering momentum. And it's what every decision in the first 30 days is aimed at.

What this looks like from where you're sitting

If you're a founder watching this unfold, the first week will feel deliberate rather than urgent. That's intentional. The quality of everything that comes after depends on the quality of the understanding built first — and rushing that understanding is where most well-intentioned interventions go wrong.

By the end of week two you should have more clarity about what's actually happening in your engineering organization than you had before — not because I've handed you a summary, but because the right questions have a way of making things that were always true finally visible.

By the end of week four you should see motion. Not a finished transformation, but a team moving with clearer direction, fewer structural obstacles, and a shared sense of what the next quarter is actually going to require of them.

That's the foundation. Everything built on top of it is faster, sturdier, and more aligned with where the business is actually trying to go.

If your team is carrying more friction than it should — or you're not sure what's causing the slowdown — let's talk about it. Engineering momentum is buildable. You just need to know where to start.

Originally published at m2s2.io

I Choose Angular Over React for Large Projects. Here’s Why.

Michael Masterson — Wed, 29 Apr 2026 01:55:37 +0000

I know what you’re thinking. The job boards say React. The bootcamps say React. Every “top frameworks 2025” listicle says React. I’m not here to tell you React is bad — it isn’t. But after 15 years across five industries, teams ranging from 3 to 20 engineers, and frontend codebases that had to survive long past their original authors, I keep reaching for Angular when the stakes are high. Here’s the honest case for why.

Let me establish some credibility first

I’m not an Angular developer who hasn’t touched React. I’ve shipped React in production — TypeScript, hooks, the whole ecosystem — on real teams with real users. I know the flexibility. I’ve felt the speed of spinning something up.

I’ve also led Angular teams building platforms and component libraries that are still in production today, maintained by engineers who had nothing to do with writing them. That last sentence is the whole argument, really.

React’s ecosystem is a feature. On large teams, it’s also a trap.

React gives you a rendering library and says “figure out the rest.” For a senior engineer who has already figured it out, that’s liberating. For a 15-person team with mixed experience levels, it’s a slow-motion debate club.

Pick your state management: Redux? Zustand? Jotai? Recoil? MobX? Context with useReducer? Each has passionate advocates and legitimate use cases. So your team has a meeting. Then another. Someone posts a benchmark. Someone else posts a counter-benchmark. Two weeks later you’ve adopted Zustand, three engineers aren’t sure why, and two secretly wish you’d picked Redux because that’s what they know.

Now do the same exercise for data fetching. React Query or SWR? RTK Query? Plain useEffect with a custom hook? Axios or fetch? And folder structure — features-based or type-based? Where do shared utilities live? What about form handling — React Hook Form, Formik, or something homegrown?

None of these are wrong questions. All of them are genuinely debatable. But on a large team, every unanswered convention is a future argument, a future inconsistency, and a future onboarding headache. The flexibility that makes React feel fast in a solo project accumulates into friction at scale.

Angular answers most of these questions before you write a single line of code. Services for state and data. HttpClient for API calls. Reactive Forms for complex form handling. A CLI that generates consistent, predictable scaffolding. You can disagree with Angular’s answers — but everyone on your team is working with the same answers, and that consistency compounds over years.

Onboarding is where this really shows up

I’ve watched senior engineers drop into large React codebases and spend weeks just mapping the terrain. Not because they weren’t capable — they absolutely were — but because every codebase has made different decisions. Different state patterns, different folder conventions, different data-fetching abstractions, all layered on top of each other as the team’s opinions evolved over time. There’s no map. You have to draw your own.

With Angular, I’ve handed a junior developer a quick tutorial and some guidance and watched them make meaningful contributions within days. Not because Angular is simpler — it isn’t — but because the conventions are already there. A new engineer knows where services live, knows how components are structured, knows how to inject a dependency. The framework is the map.

The guardrails aren’t limitations. They’re structure. And structure is what lets engineers at every level focus on solving the actual problem instead of navigating codebase archaeology.

Angular isn’t your grandfather’s framework

If the last time you seriously looked at Angular was the AngularJS era or even Angular 2–8, you’re carrying a mental model that doesn’t match the current reality. The framework has evolved dramatically.

Standalone components removed the NgModule overhead that used to be one of Angular’s most common friction points. Now a component declares its own dependencies directly — you open one file and see everything it needs. No hunting through module declarations to understand the dependency graph. With modern IDE tooling, jumping to any dependency is a keystroke away.

Signals brought a modern, explicit reactivity model that rivals anything in the React ecosystem. Zone.js is becoming optional. The bundle sizes are competitive. The developer experience — template type checking, language service, CLI — has matured to the point where it genuinely gets out of your way.

The Angular of 2026 is not what critics are usually criticizing. The framework has quietly had one of the most impressive evolution arcs in frontend history, and a lot of the React community hasn’t noticed because they stopped paying attention a few versions ago.

TypeScript first, not TypeScript adjacent

Angular was designed with TypeScript from the ground up. The compiler catches template type errors at build time — pass the wrong type to a component input, reference a property that doesn’t exist in your template, and the build fails. You find out immediately, not in production.

React with TypeScript is genuinely good. But TypeScript is optional in React, and optionality in a large codebase is a liability. You’ll inherit files written before TypeScript was added. You’ll find any used as an escape hatch. You'll see prop interfaces that diverged from reality months ago. Angular's compiler is less forgiving — and on a large team, less forgiving is a feature.

Dependency injection changes how you architect

This is the one React developers tend to wave away until they’ve lived with it. Angular’s DI system makes service boundaries explicit. You define a service, declare where it lives in the injector hierarchy, inject it where you need it. Testing becomes trivial — swap the real service for a mock and your component tests have no idea the difference.

React’s answer is context, custom hooks, and discipline. Context works. Custom hooks are elegant. But discipline is not a framework feature — it degrades over time, especially as teams grow and change. I’ve seen React codebases where data fetching logic had migrated into components because “just this once,” and that pattern had replicated itself across dozens of files. Angular’s DI doesn’t prevent bad decisions, but it makes the good patterns the path of least resistance.

Where React genuinely wins

Intellectual honesty matters here. React is the right call in real scenarios:

Ecosystem breadth — more third-party libraries, more community examples, and frankly more AI awareness. React’s dominance means LLMs have seen more React code, which matters when AI-assisted development is part of your workflow.
Hiring — more React engineers available, and that matters when you’re scaling fast
Rapid prototyping — React plus Next.js is hard to beat for getting something live quickly
React Native — if mobile is in scope, the story is much cleaner
Small teams with strong opinions — if everyone has been writing React for years with aligned conventions, you may not feel the pain points I’m describing

The framework isn’t the bottleneck. The team is.

The right framework is the one your team can stay consistent with at your current size and growth rate.

Small team, short time horizon, everyone senior — React’s flexibility is an asset. The overhead of Angular’s conventions may slow you down more than the structure helps.

Large team, long time horizon, mixed experience levels — Angular’s conventions are load-bearing. The structure isn’t overhead, it’s the thing that keeps twenty engineers pointing in the same direction eighteen months from now.

I’ve been on both sides of this. I know which late-night debugging sessions I’d rather not repeat.

At M²S², we help engineering teams make exactly these kinds of decisions — not based on what’s trending, but based on what actually works at your scale. If you’re weighing your options, let’s talk.

Using Claude to Move Faster Without Cutting Corners

Michael Masterson — Tue, 28 Apr 2026 15:46:37 +0000

There's a version of AI-assisted development that looks like this: you describe a feature, the AI writes the code, you paste it in, it mostly works, you move on. That's one way to use it. It's not the most valuable way.

I use Claude daily — for architecture decisions, code review, writing, debugging, and building features. The productivity gains are real, but they don't come from offloading thinking. They come from having a capable collaborator available at every point in the process, one that never gets tired of context, never judges a half-formed question, and can hold an entire codebase in mind while you work through a problem together.

Here's what that actually looks like in practice.

Claude as a thinking partner, not an autocomplete engine

The frame that changed how I use AI tools: Claude isn't a faster way to type. It's a faster way to think.

When I'm designing a new system, I'll describe the constraints and ask for pushback on my assumptions before writing a line of code. When I'm debugging something subtle, I'll walk through what I know and ask what I might be missing. When I'm about to make an architectural decision, I'll ask for the tradeoffs I haven't considered yet. None of that is code generation — it's structured thinking with a collaborator who has broad context and no ego.

This distinction matters because developers who treat AI as autocomplete get autocomplete-level value. Developers who treat it as a thinking partner get something closer to a senior engineer always available in the room.

What actually works

Architecture and design. Before writing code, I describe what I'm building — the constraints, the scale, the tradeoffs I'm aware of. Claude is good at surfacing tradeoffs I haven't considered and poking holes in approaches that seem solid but have hidden failure modes. This has saved me from several decisions that would have been expensive to reverse.

Boilerplate and scaffolding. The parts of development that are mechanical — setting up a new Lambda handler, wiring a new route, writing a test harness — Claude handles quickly and correctly. This isn't the interesting part of the work, and not spending mental energy on it means more for the parts that matter.

Code review and refactoring. I'll share a function and ask what I'm missing — edge cases, error conditions, performance issues, readability problems. It catches things I'm too close to see. It's not infallible, but the hit rate is high enough that I treat it as a mandatory step before pushing anything significant.

Writing. Documentation, commit messages, technical explanations, posts like this one. Having a collaborator who can help sharpen an argument or tighten a paragraph without changing the voice is genuinely useful.

I don't vibe code

There's a style of AI-assisted development that's become popular — describe what you want, accept whatever comes out, repeat. I don't work that way.

My process is closer to: prompt, plan, review. Before any significant piece of work, I'll use Claude's plan mode to lay out the approach — what files change, what the logic looks like, what the edge cases are. I read the plan. I push back on parts that don't look right. I ask questions. Only once I understand and agree with the direction do I let it execute.

The same applies to output. Every piece of code Claude produces gets reviewed before it lands. Not a quick skim — an actual read. I want to understand what it did and why. If I can't explain it, I ask until I can. This isn't distrust, it's ownership. Code I don't understand is a liability I'm carrying.

The developers who get burned by AI tooling are usually the ones who skipped this step. The ones who get consistent value treat the AI output as a strong first draft from a collaborator — not a finished answer from an authority.

The skill that actually determines your results

Prompting is a real skill, and it compounds. The developers getting the most out of Claude aren't the ones with the most AI experience — they're the ones who communicate precisely, provide relevant context, and ask specific questions instead of vague ones.

"Fix this function" gets worse results than "This function is supposed to do X, it's currently doing Y in edge case Z, here's what I've already tried." The more precisely you can describe what you know, what you want, and what constraints matter, the better the output.

The fastest way to improve: treat every unsatisfying response as a prompt quality problem first. Reframe the question, add context, be more specific about what you actually need. You'll get better at it quickly.

The meta point

The platform this blog runs on — the Angular frontend, the Go Lambda API, the CDK infrastructure — was built with Claude as a constant collaborator. Not generated wholesale, but developed in a genuine back-and-forth: I set the direction and made the decisions, Claude helped me move faster and caught things I missed. The result is code I understand completely and can maintain confidently.

That's the model I'd advocate for. AI in service of your judgment, not a replacement for it.

At M²S² Engineering Group, we build with the best tools available — including AI. If you're figuring out how to integrate these workflows into your team's practice, let's talk.

Originally published at m2s2.io

Modern Angular Architecture: From NgModules to Standalone Components

Michael Masterson — Tue, 28 Apr 2026 15:46:35 +0000

NgModules were Angular's answer to a real problem: how do you organize a large application into logical units, share dependencies, and lazy-load chunks of functionality? The answer worked. It was also verbose, confusing to newcomers, and responsible for some of the most baffling error messages in frontend development.

Standalone components — stable since Angular 15, the default since Angular 17 — solve the same problems with significantly less ceremony. I've migrated a production application through this transition and built new ones from scratch with the standalone model. Here's what actually matters.

The mental model shift

In the NgModule world, a component is a member of a module. The module declares what the component can use. You want to use RouterLink in a component? Add RouterModule to the module's imports. You want to use another component? Either declare it in the same module or import the module that exports it.

This creates a layer of indirection that makes components non-portable. A component's dependencies are defined somewhere else, by someone else, possibly a long time ago. New team members spend their first weeks asking "why can't I use X here" and the answer is always somewhere in a module file.

In the standalone model, the component owns its dependencies:

@Component({
  selector: 'app-dashboard',
  templateUrl: './dashboard.component.html',
  standalone: true,
  imports: [NgIf, NgFor, NgClass, RouterLink],
})
export class DashboardComponent { }

Everything the template needs is declared right here. You can open this file cold and know exactly what it depends on without hunting through module trees. That's not a small thing — it compounds across a codebase.

inject() over constructor injection

Standalone components pair naturally with the inject() function, which lets you inject dependencies without a constructor parameter list:

// Old pattern
export class MyComponent {
  constructor(
    private readonly router: Router,
    private readonly authService: AuthService,
    private readonly contentService: ContentService,
  ) {}
}

// New pattern
export class MyComponent {
  private readonly router         = inject(Router);
  private readonly authService    = inject(AuthService);
  private readonly contentService = inject(ContentService);
}

This isn't just a style preference. inject() works in any injection context — component constructors, service factories, route guards — which means you can extract reusable injection logic into plain functions without creating a service class for it. It also makes the dependencies easier to read at a glance since each one is on its own line with its type visible.

Signals: the reactive layer that finally makes sense

Angular 16 introduced signals as a new reactive primitive, and they fit the standalone model naturally. Where you'd previously reach for BehaviorSubject or complex async pipe chains, signals give you a simpler model:

export class AdminComponent {
  readonly inquiries  = signal<Inquiry[]>([]);
  readonly activeTab  = signal<'inquiries' | 'visitors'>('inquiries');
  readonly loading    = signal(true);

  // computed() derives state — recalculates only when dependencies change
  readonly inquiryCount = computed(() => this.inquiries().length);
}

The key insight: a signal is just a value with change notification built in. You read it by calling it like a function — this.loading() — and write it with .set() or .update(). Angular tracks which signals a template reads and re-renders only when those specific signals change.

For auth state in particular, signals are a significant improvement. Rather than maintaining a subscription and manually updating component state, you expose a signal from a service and components derive from it with computed():

// Service
readonly session = signal<SessionInfo>(UNAUTHENTICATED);

// Component — updates automatically whenever session changes
readonly navConfig = computed(() => this.buildConfigForRole(this.authService.session()));

No subscriptions. No ngOnDestroy. No memory leaks from forgotten unsubscribes.

Lazy loading without modules

Lazy loading used to require a routing module and a loadChildren callback that imported it. Now it's a single line:

// Before
{
  path: 'dashboard',
  loadChildren: () => import('./dashboard/dashboard.module').then(m => m.DashboardModule)
}

// After
{
  path: 'dashboard',
  loadComponent: () => import('./dashboard/dashboard.component').then(c => c.DashboardComponent)
}

The bundle split is identical. The module is gone. For route groups you still have loadChildren, but it now accepts an array of routes rather than a module.

Migration strategy that actually works

If you're migrating an existing app, go leaf-first. Start with components that have no children of their own — the deepest nodes in the component tree. Add standalone: true and move their dependencies into the component's imports array. Then work inward toward shared components, then feature components, then the root.

The Angular CLI has a migration schematic that handles most of this automatically:

ng generate @angular/core:standalone

Run it in stages — it gives you options for converting components, removing unnecessary NgModule imports, and bootstrapping as standalone. Use git diff aggressively between each stage to review what changed.

CommonModule imports. You'll find CommonModule in a lot of module import lists because it's the easy way to get NgIf, NgFor, and the async pipe. In standalone components, import only what you need — NgIf, NgFor, AsyncPipe — individually. It's more verbose initially but makes tree-shaking more effective.

Shared services don't change. Services with providedIn: 'root' work exactly the same. You don't need to touch them. The standalone migration is a component-level change, not a service-level one.

HTTP interceptors move to bootstrapApplication. If you use HTTP interceptors, they're now registered with withInterceptors() in the bootstrapApplication call rather than in a module provider array. Easy to miss, and it fails silently if you forget.

Third-party libraries may lag. Some Angular libraries still export NgModules and haven't published standalone-compatible exports. You can still import a module into a standalone component's imports array — it works — but check whether newer versions of the library offer standalone APIs before importing the whole module.

Is it worth the migration effort?

For a new project: yes, unambiguously. Build standalone from the start. The mental model is simpler, the tooling assumes it, and new Angular features are being designed around it.

For an existing app: it depends on the size and stability of the codebase. A large, stable NgModule-based app that isn't causing problems doesn't urgently need migration. A growing codebase with new features being added regularly will benefit from the migration — but do it incrementally, not all at once.

At M²S² Engineering Group, we help teams make exactly these kinds of decisions — whether to migrate, how to sequence it, and how to do it without disrupting ongoing delivery. If you're navigating a modernization and want to talk it through, let's talk.

Originally published at m2s2.io

Engineering Leadership: What Nobody Tells You Before You Take the Job

Michael Masterson — Tue, 28 Apr 2026 14:32:14 +0000

I didn't plan to become an engineering manager. I was a senior engineer who cared deeply about how the team worked, and at some point that care turned into a title. What followed was a crash course in everything a technical background doesn't prepare you for.

I've led teams of 9 and 20 — onshore, nearshore, and offshore — through greenfield builds, legacy migrations, platform rewrites, and ambiguous mandates with moving deadlines. These are the things I wish someone had told me before I started.

Your output is no longer code

This sounds obvious. It isn't, really — not until you feel it. Early in my first management role I kept finding myself drifting back to the IDE. It felt productive. It was familiar. It was also the wrong use of my time.

As an IC, your output is what you ship. As a manager, your output is what your team ships. Those are different jobs. The sooner you internalize that, the sooner you start spending your time on the things that actually multiply the team's output — clearing blockers, making decisions, setting direction, hiring well, and building the kind of environment where engineers can do their best work without constantly checking with you first.

That last part — reducing your own necessity — is the hardest thing to learn and the most important.

Ambiguity is the job, not an obstacle to it

Engineers are trained to solve well-defined problems. Management is largely the practice of operating in conditions where the problem isn't well-defined, the requirements will change, and someone above you wants a date.

I've been handed teams mid-rebuild with mandates to modernize platforms that had been accumulating technical debt for years. Scope changed constantly. Stakeholder priorities shifted week to week. There was no clear finish line. The job was to keep the team moving productively despite that, not to wait for clarity that was never coming.

The engineers who struggled most in that environment were the ones waiting for permission to move. The ones who thrived understood that forward motion with imperfect information beats paralysis while waiting for a perfect spec. Your job as a leader is to model that — and to create enough safety that your team feels the same way.

Trust is built in small moments, not big ones

I've seen managers try to build team trust through all-hands talks, offsites, and team-building events. Those things aren't bad, but they're not where trust actually gets built.

Trust is built when you fight for someone's promotion and they find out. When you take the blame in a postmortem instead of pointing at the engineer who made the call. When you remember what someone said in a 1:1 three weeks ago and follow up on it without being asked. When you give direct feedback early instead of letting something fester into a performance conversation six months later.

None of those are dramatic moments. They're small, repeated actions over time. That's what trust is made of.

Technical direction has to be set, not consensus-built

There's a version of technical leadership where every architecture decision goes through the whole team, everyone has a voice, and nothing gets decided until there's buy-in. I understand the instinct. It backfires constantly.

Teams move fast when they have clear guardrails — approved patterns, defined standards, explicit rules about what's off-limits — and then autonomy inside those guardrails. What they can't do is move fast when every decision requires a committee.

I've defined frontend and backend standards that became the baseline for all platform development across teams. Engineers didn't need to ask whether to use a certain pattern — the answer was already documented. That eliminated an enormous amount of friction. The team made more decisions independently, shipped more consistently, and had better code quality than any team I'd seen operate by pure committee.

This doesn't mean you don't listen. It means you listen, decide, document, and then hold the line — revisiting when there's real evidence the direction needs to change, not just because someone prefers a different approach.

Hiring is the highest-leverage thing you do

Everything else on this list — direction, trust, standards, culture — compounds if you have the right people and collapses if you don't. One mis-hire in a key role can consume more of your time and team energy than any technical problem you'll face.

I've hired dozens of engineers across multiple organizations. The most effective change I made was introducing AI-assisted assessments that gave consistent, role-specific evaluations for every candidate. The result was a more defensible hiring bar, less prep time, and — critically — fewer late-stage surprises when someone's actual ability didn't match how they presented in an interview.

What I look for beyond technical skill: how does someone operate when they don't have enough information? Do they ask good questions or just wait? Can they disagree directly without being difficult? Have they shipped something that actually worked? Those signals matter more than algorithm fluency at a whiteboard.

Managing up is a skill, not a concession

Early on I thought managing up — keeping stakeholders informed, shaping expectations, making the team's work legible to leadership — was a distraction from real work. I was wrong.

Leadership above you is making decisions with incomplete information. If you're not providing that information, someone else is — and their version of events may not reflect what's actually happening. Proactively communicating status, surfacing risks before they're crises, and framing technical trade-offs in business terms isn't politics. It's protecting your team from decisions made in a vacuum.

The cleaner your communication upward, the more autonomy you earn downward. That's the deal.

The thing that actually determines whether a team ships

After years of this, I've come to believe that the single biggest predictor of team output isn't process, tooling, or even talent. It's psychological safety — the degree to which engineers feel safe raising problems, asking questions, and being wrong in front of each other.

Teams with high safety surface bugs earlier. They escalate sooner. They try things that might not work. They tell you when a deadline isn't realistic instead of staying quiet and missing it. Teams without safety hide problems until they're catastrophic, defer hard conversations, and optimize for looking good over doing good work.

You create it by being honest about what you don't know. By treating mistakes as information rather than failures. By rewarding the person who raised a concern early over the person who stayed quiet and got lucky. It takes a long time to build and almost no time to destroy.

At M²S² Engineering Group, engineering leadership is part of every engagement — not an afterthought. Whether you need an embedded partner or someone to help set direction, let's talk about what that looks like.

Originally published at m2s2.io

What a Fractional Engineering Leader Actually Does

Michael Masterson — Thu, 23 Apr 2026 00:34:42 +0000

Most founders who reach out to a fractional engineering leader have the same question underneath whatever they actually ask: is this a real thing, and is it for me?

It’s a fair question. The term gets used loosely — sometimes it means a part-time hire, sometimes a consultant, sometimes an advisor who shows up to a monthly call. The ambiguity makes it hard to evaluate. So let me be direct about what it actually means in practice.

What it is

A fractional engineering leader is a senior technical partner who embeds with your team on a part-time basis — typically a set number of days per week — and takes on real ownership of the engineering function. Not advisory. Not oversight. Actual responsibility for the decisions, direction, and execution quality of what your team builds.

That means setting technical standards, making architecture calls, running the hiring process, managing engineers, communicating with stakeholders, and being accountable for delivery. The same things a full-time CTO or VP of Engineering would own — delivered at a scope and cost that matches where you actually are.

Who it’s for

The companies that get the most out of this model tend to look like one of these:

The technical founder who’s outgrown the role.

You built the first version. You’re still the most senior engineer on the team. But you’re also running product, talking to customers, and trying to close deals. Engineering decisions are getting deferred, standards are slipping, and you know it. You need someone to own the technical function so you can focus on the business.

The non-technical founder with engineers.

You have a team building something. You can evaluate business outcomes but not the quality of the decisions underneath them. You need a trusted technical partner who can tell you what’s actually going on, make the calls you can’t, and be honest with you when something is heading in the wrong direction.

The growing team that needs structure.

You’ve scaled past the point where everything fits in one person’s head, but you’re not ready — or don’t need — a full-time executive. You need patterns, standards, and someone who’s built at this stage before to set the foundation before it becomes expensive to fix.

What it actually looks like

The specifics vary by engagement, but the shape is usually consistent: a defined number of days per week, clear ownership of the engineering function, and regular communication with whoever is running the business.

In practice that means being present in the work — in code reviews, architecture discussions, hiring conversations, and planning sessions — not just showing up to give opinions. It means knowing the codebase, knowing the team, and being accountable for the output. An engagement that stays at the advisory layer isn’t really fractional leadership. It’s expensive consulting.

The best engagements feel like a founding team member who happens to work a structured schedule. The worst ones have unclear ownership and a leader who isn’t close enough to the work to make good decisions. The difference is usually defined scope and real accountability from the start.

What it isn’t

It isn’t a shortcut. A fractional leader can move fast because they’ve seen these problems before, but they still need time to understand your context, your team, and your constraints. Expect a ramp period. Expect to invest in the relationship.

It also isn’t a replacement for eventually building a full-time engineering leadership function if that’s where you’re headed. The best fractional engagements either solve a specific problem and conclude cleanly, or they set the foundation well enough that bringing on a full-time leader becomes a natural next step — with a codebase, team, and standards in good shape when they arrive.

How to know if it’s the right call

A few honest signals:

You’re making technical decisions you’re not confident in, and you know it.
Engineering is moving slower than it should and you can’t pinpoint why. Things are moving fast — maybe too fast — and there’s no senior voice in the room to slow down, ask the hard questions, and make sure the foundation holds up under the pace.
Your team is growing and nobody is setting the bar for how things get built.
You’ve interviewed for a full-time CTO and haven’t found the right person, or the role doesn’t justify a full-time salary yet.

Any of those is a reasonable starting point for a conversation.

At M²S² Engineering Group, fractional engineering leadership is one of the core ways we engage — embedded, accountable, and focused on the work that actually moves things forward. If any of this sounds like where you are, let’s talk.

My Terminal-Native Dev Setup: WezTerm and Neovim

Michael Masterson — Wed, 22 Apr 2026 13:48:45 +0000

April 20, 2026

Most developers reach for VS Code by default. It’s a reasonable choice — good ecosystem, low friction, gets out of your way. I used it for years. At some point I started paying attention to how much time I spent with my hands off the keyboard, reaching for the mouse to navigate, click through file trees, manage tabs. It adds up.

I’ve been running WezTerm and Neovim as my primary development environment for a while now. I work across Go, TypeScript, and Angular — a reasonably demanding setup that requires solid LSP support, fast navigation, and a terminal that doesn’t slow me down. Here’s what I’ve learned.

Why WezTerm over everything else

The terminal landscape is crowded. iTerm2, Alacritty, Kitty, Ghostty — all solid. I landed on WezTerm for a few specific reasons.

It’s configured in Lua. That sounds minor but it matters: the config file is a real programming language, not an INI file with magic strings. You can write functions, conditionals, and abstractions. Here’s a minimal starting point:

local wezterm = require 'wezterm'
local config = wezterm.config_builder()

config.font = wezterm.font('FiraCode Nerd Font', { weight = 'Regular' })
config.font_size = 14.0
config.color_scheme = 'Tokyo Night'
config.enable_tab_bar = true
config.hide_tab_bar_if_only_one_tab = true
config.window_padding = { left = 8, right = 8, top = 8, bottom = 8 }

return config

WezTerm also has a built-in multiplexer, and I use it heavily. Tab management is handled entirely through keyboard shortcuts — opening, closing, and switching tabs without touching the mouse. Each tab is a context: a project, a running process, a scratch environment. When I’m inside Neovim, I hand off navigation entirely to its internal buffer management and fuzzy search tooling. The two layers stay clean and don’t fight each other.

GPU rendering means it stays fast even with large outputs. And it works identically on macOS and Linux, which matters when you’re working across machines.

Why Neovim over VS Code

This is the more loaded question, and I want to be honest about it: Neovim is not better than VS Code in every way. The plugin ecosystem is more fragmented, setup takes real time, and new contributors to a project can’t just open your config and understand it immediately.

What Neovim does better: speed, keyboard-centricity, and composability. Once you internalize modal editing — the idea that you’re either navigating or editing, not both simultaneously — the efficiency difference is real. Motions like ciw (change inner word), va{ (select around braces), or % (jump to matching bracket) stop being things you remember and start being things you reach for without thinking.

The LSP support in modern Neovim is excellent. With mason.nvim handling server installation and nvim-lspconfig wiring them up, you get the same language intelligence VS Code has — autocompletion, go-to-definition, inline diagnostics, rename across files — without a separate application running.

The plugin stack that actually matters

There are a thousand Neovim plugin lists. Most include too much. Here’s what I actually use daily:

lazy.nvim — plugin manager. Lazy-loads plugins so startup stays fast.

telescope.nvim — fuzzy finder for files, grep, LSP symbols, git history. This is the single highest-leverage plugin in the ecosystem. ff to find a file and fg to grep across the project replace most file tree navigation.

nvim-treesitter — syntax highlighting and code understanding via AST parsing rather than regex. Makes highlighting accurate and enables smart text objects.

nvim-cmp — completion engine. Pulls from LSP, snippets, buffer words. Feels like IDE completion once configured.

gitsigns.nvim — inline git blame, hunk staging, diff previews in the gutter. The kind of thing you don't know you need until you have it.

conform.nvim — formatting on save, language-aware. Runs gofmt on Go files, prettier on TypeScript, without you thinking about it.

A minimal plugin setup with these six gets you 90% of the way to a full IDE experience.

How WezTerm and Neovim work together

The short version: WezTerm is the container, Neovim is the environment. WezTerm handles font rendering, color, and tab management. Neovim handles editing, navigation, and LSP.

I use WezTerm’s tab system for context switching — one tab per project or major task — and Neovim’s buffer and split system for everything within a project. The combination keeps me in the keyboard almost entirely. A typical navigation sequence: ff to jump to a file, gd to go to a definition, to jump back, fg to grep for a usage. No mouse involved.

Terminal commands stay in a dedicated WezTerm tab rather than Neovim’s built-in terminal, which keeps the separation clean.

The learning curve is real, and that’s fine

I’m not going to undersell this. Getting productive in Neovim takes weeks, not hours. Vim motions have to become muscle memory, and that only happens through deliberate repetition — not reading about them.

The path that worked for me: I started with VS Code in Vim mode. Not Neovim, not a terminal editor — just the Vim keybindings extension in an environment I already knew. That removed the “where is everything” friction and let me focus entirely on building motion muscle memory. I also spent time with Vim Adventures, a browser game that teaches Vim navigation through actual gameplay. It sounds gimmicky. It works.

By the time I moved to Neovim full-time, the motions were already there. The transition became about configuration and workflow, not simultaneously learning a new editor and a new input model.

The other thing that helped: don’t try to replicate your VS Code setup in Neovim. Start with less than you think you need. Add things when you feel a specific friction, not because a blog post said you should. The instinct to add plugins until it feels familiar is how you end up with a config you don’t understand.

Is it worth it?

For me, yes — clearly. The speed, the composability, the satisfaction of a workflow that fits exactly how I think. But the honest answer is: it depends on what you optimize for. If you want to minimize setup time and maximize immediate productivity, VS Code wins. If you want an environment you can tune to exactly how your brain works and that will feel faster every month you use it, Neovim is worth the investment.

At M²S² Engineering Group, the tools are always in service of the work — not the other way around. If you’re thinking through your team’s developer experience or how tooling choices affect velocity, let’s talk.

Building a Serverless REST API with Go and AWS Lambda

Michael Masterson — Tue, 21 Apr 2026 17:20:23 +0000

November 11, 2025

I’ve built Go Lambda APIs a few different ways over the years. Some of those experiments are in production right now — including the API that powers this site. What follows is the pattern I’ve landed on: clean, minimal, and straightforward to operate.

The short version: Go is one of the best Lambda runtimes available. Fast cold starts, a single static binary, a strong standard library, and a compiler that catches whole categories of runtime errors before they reach production. If you’re starting a new serverless API and aren’t already committed to another language, this is the stack I’d reach for.

Why Go specifically

Lambda cold starts are real. A Go function compiled to a Linux arm64 binary typically initializes in under 100ms — often under 50ms. Compare that to Node.js or Python runtimes that need to load an interpreter and dependencies before your first line of code runs. For a public-facing API, that difference matters.

The other thing Go gives you is a single self-contained binary. No node_modules, no virtual environments, no dependency resolution at deploy time. You compile locally, upload a zip file, and the Lambda runtime executes it directly. That simplicity pays dividends when you're debugging at 2am.

Project structure

Here’s how I structure a Go Lambda project in a monorepo:

apps/api/
├── contact/
│ └── main.go # POST /contact handler
├── dashboard/
│ └── main.go # Auth-gated routes
└── shared/
    ├── models.go # DynamoDB item structs
    ├── dynamo.go # Query/put helpers
    ├── mailer.go # SES wrapper
    └── util.go # ID generation, CORS headers

Each Lambda function gets its own directory with a main.go. Common code lives in shared/ as an internal package. This avoids the mistake of deploying a massive monolith Lambda that does everything — instead, each function has a focused responsibility and independent deploy surface.

The shared package is where you put things that would otherwise be copy-pasted: DynamoDB helpers, the SES wrapper, CORS headers, ID generation. Keep it lean. If something is only used in one function, it stays in that function's package.

The handler pattern

Every Lambda handler has the same shape: receive an events.APIGatewayV2HTTPRequest, return an events.APIGatewayV2HTTPResponse. I put all routing inside a single handler function using a switch on method + path:

func handler(ctx context.Context, req events.APIGatewayV2HTTPRequest) (events.APIGatewayV2HTTPResponse, error) {
    headers := shared.CORSHeaders(allowedOrigin, "GET, POST, OPTIONS", "Content-Type, Authorization")
    method := req.RequestContext.HTTP.Method
    path := req.RequestContext.HTTP.Path

    if method == "OPTIONS" {
        return events.APIGatewayV2HTTPResponse{StatusCode: 204, Headers: headers}, nil
    }

    switch {
    case method == "POST" && path == "/contact":
        return handleContact(ctx, req, headers)
    case method == "GET" && path == "/health":
        return events.APIGatewayV2HTTPResponse{StatusCode: 200, Headers: headers, Body: `{"ok":true}`}, nil
    default:
        return errResponse(404, "not found", headers), nil
    }
}

This is simpler than it looks. You don’t need a router library for a Lambda that handles 3–5 routes. The switch is readable, the cases are explicit, and there’s no magic. If a function grows beyond ~10 routes, that’s a signal it should be split.

Reading the JWT for auth-gated routes

API Gateway v2 with a Cognito JWT authorizer makes auth simple. The claims are injected into the request context — no token validation code needed in your Lambda:

func jwtEmail(req events.APIGatewayV2HTTPRequest) string {
    if req.RequestContext.Authorizer == nil {
        return ""
    }
    email, _ := req.RequestContext.Authorizer.JWT.Claims["email"]
    return email
}

func isAdmin(req events.APIGatewayV2HTTPRequest) bool {
    if req.RequestContext.Authorizer == nil {
        return false
    }
    groups := req.RequestContext.Authorizer.JWT.Claims["cognito:groups"]
    return strings.Contains(groups, "admin")
}

The Cognito authorizer rejects requests with invalid or expired tokens before they reach your code. Your handler only runs for requests that passed auth — so a missing or empty email is a programming error, not a security gap.

Building and deploying with CDK

The build step is straightforward. For each Lambda, you cross-compile to Linux arm64 and zip the binary:

GOOS=linux GOARCH=arm64 go build -o bootstrap ./apps/api/contact/
zip contact.zip bootstrap

The CDK stack in Go defines the function pointing at that zip:

contactFn := awslambda.NewFunction(stack, jsii.String("ContactFn"), &awslambda.FunctionProps{
    Runtime: awslambda.Runtime_PROVIDED_AL2023(),
    Handler: jsii.String("bootstrap"),
    Code: awslambda.Code_FromAsset(jsii.String("../../apps/api/contact.zip"), nil),
    Environment: &map[string]*string{
        "TABLE_NAME": jsii.String(*table.TableName()),
        "FROM_EMAIL": jsii.String(fromEmail),
        "ALLOWED_ORIGIN": jsii.String(allowedOrigin),
    },
})

Wire the function to API Gateway, add a Cognito JWT authorizer for protected routes, and deploy. The whole stack — Lambda, API Gateway, DynamoDB table, IAM roles — comes up in a single cdk deploy.

The gotchas

A few things that aren’t obvious until you hit them:

The binary must be named bootstrap. The provided.al2023 runtime looks for a file named exactly bootstrap in the zip. Name it anything else and you'll get a cryptic runtime error on first invocation.

CORS preflight has to be handled explicitly. API Gateway v2 can handle CORS for you, or your Lambda can. Do one or the other — not both. If your Lambda returns CORS headers and the gateway also injects them, you’ll get duplicate headers and browsers will reject the response.

Cold start is not your P99. Cold starts only happen when a new execution environment is provisioned. Under steady traffic, most requests hit warm instances. Don’t optimize for cold start at the cost of readability — it’s rarely the bottleneck you think it is.

DynamoDB errors are usually IAM. If your Lambda can’t read or write to DynamoDB, check the execution role permissions before assuming your code is wrong. The AWS SDK swallows permission errors in ways that make them look like connection issues.

Is it worth it?

For the right workload — yes, absolutely. A Go Lambda API with DynamoDB behind API Gateway has essentially zero operational overhead. No servers to patch, no auto-scaling groups to tune, no capacity planning for moderate traffic. You pay for what you use, and Go’s efficiency means you use very little.

Where it breaks down: workloads that need persistent connections (WebSockets, long-running jobs), very high concurrency with unpredictable bursts (Lambda has account-level concurrency limits), or anything that genuinely benefits from a stateful server process. Know the constraints going in and it’s a powerful tool.

At M²S² Engineering Group, we help teams navigate exactly these kinds of architecture decisions — whether that’s serverless, containers, or something in between. If you’re weighing your options or just want a second opinion, let’s talk.

Engineering Leadership: What Nobody Tells You Before You Take the Job

Michael Masterson — Tue, 21 Apr 2026 12:23:29 +0000

Engineering Leadership

I didn’t plan to become an engineering manager. I was a senior engineer who cared deeply about how the team worked, and at some point that care turned into a title. What followed was a crash course in everything a technical background doesn’t prepare you for.

I’ve led teams of many engineers (full-time, onshore, nearshore, and offshore) through greenfield builds, legacy migrations, platform rewrites, and ambiguous mandates with moving deadlines. These are the things I wish someone had told me before I started.

Your output is no longer code

This sounds obvious. but it isn’t, really. Not until you truly feel it. Early in my first management role I kept finding myself drifting back to the IDE. It felt productive. It was familiar. It was also the wrong use of my time.

As an IC, your output is what you ship. As a manager, your output is what your team ships. Those are different jobs. The sooner you internalize that, the sooner you start spending your time on the things that actually multiply the team’s output — clearing blockers, making decisions, setting direction, hiring well, and building the kind of environment where engineers can do their best work without constantly checking with you first.

That last part — reducing your own necessity — is the hardest thing to learn and the most important.

Ambiguity is the job, not an obstacle to it

Engineers are trained to solve well-defined problems. Management is largely the practice of operating in conditions where the problem isn’t well-defined, the requirements will change, and someone above you wants a date.

I’ve been handed teams mid-rebuild with mandates to modernize platforms that had been accumulating technical debt for years. Scope changed constantly. Stakeholder priorities shifted week to week. There was no clear finish line. The job was to keep the team moving productively despite that, not to wait for clarity that was never coming.

The engineers who struggled most in that environment were the ones waiting for permission to move. The ones who thrived understood that forward motion with imperfect information beats paralysis while waiting for a perfect spec. Your job as a leader is to model that and to create enough psychological safety that your team feels the same way.

Trust is built in small moments, not big ones

I’ve seen managers try to build team trust through all-hands talks, offsites, and team-building events. Those things aren’t bad, but they’re not where trust actually gets built.

Trust is built when you fight for someone’s promotion and they find out. When you take the blame in a postmortem instead of pointing at the engineer who made the call. When you remember what someone said in a 1:1 three weeks ago and follow up on it without being asked. When you give direct feedback early instead of letting something fester into a performance conversation six months later.

None of those are dramatic moments. They’re small, repeated actions over time. That’s what trust is made of.

Technical direction has to be set, not consensus-built

There’s a version of technical leadership where every architecture decision goes through the whole team, everyone has a voice, and nothing gets decided until there’s buy-in. I understand the instinct. It backfires constantly.

Teams move fast when they have clear guardrails — approved patterns, defined standards, explicit rules about what’s off-limits — and then autonomy inside those guardrails. What they can’t do is move fast when every decision requires a committee.

I’ve defined frontend and backend standards that became the baseline for all platform development across teams. Engineers didn’t need to ask whether to use a certain pattern, the answer was already documented. That eliminated an enormous amount of friction. The team made more decisions independently, shipped more consistently, and had better code quality than any team I’d seen operate by pure committee.

This doesn’t mean you don’t listen. It means you listen, decide, document, and then hold the line — revisiting when there’s real evidence the direction needs to change, not just because someone prefers a different approach.

Hiring is the highest-leverage thing you do

Everything else on this list (direction, trust, standards, culture) compounds if you have the right people and collapses if you don’t. One mis-hire in a key role can consume more of your time and team energy than any technical problem you’ll face.

I’ve hired dozens of engineers across multiple organizations. The most effective change I made was introducing AI-assisted assessments that gave consistent, role-specific evaluations for every candidate. The result was a more defensible hiring bar, less prep time, and — critically — fewer late-stage surprises when someone’s actual ability didn’t match how they presented in an interview.

What I look for beyond technical skill: how does someone operate when they don’t have enough information? Do they ask good questions or just wait? Can they disagree directly without being difficult? Have they shipped something that actually worked? Those signals matter more than algorithm fluency at a whiteboard.

Managing up is a skill, not a concession

Early on I thought managing up — keeping stakeholders informed, shaping expectations, making the team’s work legible to leadership — was a distraction from real work. I was wrong.

Leadership above you is making decisions with incomplete information. If you’re not providing that information, someone else is — and their version of events may not reflect what’s actually happening. Proactively communicating status, surfacing risks before they’re crises, and framing technical trade-offs in business terms isn’t politics. It’s protecting your team from decisions made in a vacuum.

The cleaner your communication upward, the more autonomy you earn downward. That’s the deal.

The thing that actually determines whether a team ships

After years of this, I’ve come to believe that the single biggest predictor of team output isn’t process, tooling, or even talent. It’s psychological safety — the degree to which engineers feel safe raising problems, asking questions, and being wrong in front of each other.

Teams with high safety surface bugs earlier. They escalate sooner. They try things that might not work. They tell you when a deadline isn’t realistic instead of staying quiet and missing it. Teams without safety hide problems until they’re catastrophic, defer hard conversations, and optimize for looking good over doing good work.

You create it by being honest about what you don’t know. By treating mistakes as information rather than failures. By rewarding the person who raised a concern early over the person who stayed quiet and got lucky. It takes a long time to build and almost no time to destroy.

At M²S² Engineering Group, engineering leadership is part of every engagement — not an afterthought. Whether you need an embedded partner or someone to help set direction, click the link and let’s talk about what that looks like.

M2S2 Engineering Group