Kondaurov | Blog

Building a simpler AWS deploy tool

Fri, 10 Apr 2026 12:00:00 GMT

I’m a software engineer with over 12 years of experience across different languages, teams, and dozens of projects. I love what I do, and I’m drawn to solving real problems with clean tools.

I’ve been building serverless applications on AWS for years. Across multiple jobs and projects, I’ve used Serverless Framework and AWS CDK. And there was always this friction — the gap between having an idea and getting it running in the cloud felt wider than it should be.

This is the story of why I finally snapped and built my own deployment tool — one that skips CloudFormation entirely and deploys AWS resources with direct API calls.

The Background

My serverless journey started with Serverless Framework — it was the go-to tool at the time, and it worked. Then AWS CDK came along promising infrastructure as “real code,” and I jumped in. I spent a lot of time with CDK commercially, building stacks, configuring resources, trying to get everything just right.

I’ve also worked with other clouds — Google Cloud and Firebase in particular. And honestly, Firebase left an impression on me. The way you could describe your functions in code, run a single CLI command, and have everything deployed — that felt like how things should work.

That said, I always preferred AWS itself. Google Cloud felt overcomplicated — containers everywhere, things weren’t obvious. AWS Lambda was simpler: no container builds, functions spun up fast, and the whole model just made more sense to me. So I loved Firebase’s developer experience, but I wanted it on AWS.

The Pain

With AWS CDK, I constantly found myself solving infrastructure puzzles instead of shipping features. How do I split stacks so that Lambda functions deploy faster, separate from the databases? How do I configure bundling — should I use tsup externally, or let CDK handle it? Every project started with the same yak-shaving.

And then there was CloudFormation. Every deployment meant waiting for CloudFormation to diff, plan, and roll out changes — even for a one-line code fix. For large projects with hundreds of resources, maybe that’s an acceptable trade-off. But for serverless, where the whole point is agility, it felt like dragging an anchor.

I wanted a fast loop: change code, deploy, see results. Instead, I was spending my time debugging stack configurations and staring at UPDATE_IN_PROGRESS for minutes.

The Inspiration

At some point I discovered something on my own: you can create AWS resources directly through the AWS SDK. No CloudFormation needed. And it’s much faster — the end result is exactly the same, but you skip the entire provisioning engine. That was the moment it clicked: combine Firebase’s code-as-config model with direct AWS SDK calls, and you get the best of both worlds.

What I Built

What if you could just write your Lambda handler, declare its configuration right next to the code, and run a single command to deploy everything? No CloudFormation templates. No stack definitions. No bundler config. No IAM boilerplate.

The biggest challenge was clear from the start: I’d need to do what CloudFormation does — compare current state with desired state and sync the difference — but without CloudFormation, using direct AWS SDK calls. That’s not a trivial problem.

Three libraries gave me the confidence to try.

ts-morph — a fantastic library for analyzing TypeScript AST. It’s essentially metaprogramming: I could extract all the infrastructure information directly from handler code instead of keeping it in separate YAML or JSON files.

Effect-TS — the project was going to be complex, orchestrating API calls, managing errors, handling concurrency. Effect gave me a way to write that kind of code without the cognitive load spiraling out of control as the codebase grew.

And a typed AWS SDK wrapper I had built a couple of years ago — a generator that reads JSDoc from AWS SDK source, extracts all possible error types, and produces Effect wrappers where every error is known at the type level.

With these tools in hand, I set out to build effortless-aws.

Finding the right API took time. Firebase inspired the direction, but I didn’t love everything about it. I wanted something where every handler is a single function call that takes one options object — path, method, handler logic, dependencies, parameters, everything in one place. No curried functions, no builder chains. Just one object that’s easy to read and extend.

Effect-TS inspired me here too — specifically its approach to context and built-in dependency injection. In Effect, you can verify at the type level that all dependencies are satisfied before running anything. I wanted the same for my handlers: you declare a setup factory at the Lambda level, and it’s injected into every request handler with full type safety. No runtime surprises where something is undefined because you forgot to wire it up.

This matters because some handlers need references to other resources — a Lambda that writes to a DynamoDB table, for example. A single config object makes that natural: you just add a deps field. Everything — setup, deps, params — is type-checked and injected automatically.

Here’s what the simplest handler looks like:

import { defineApi } from "effortless-aws";

export const hello = defineApi({ basePath: "/hello" })
  .get("/", async () => ({
    status: 200,
    body: { message: "Hello World!" },
  }));

That’s your Lambda function, its Function URL, and its IAM role — all in one file. Run eff deploy and it’s live.

Before and After

To appreciate the difference, here’s what it takes to create a simple HTTP endpoint with a DynamoDB table in CDK:

// CDK: stack definition (separate file)
const table = new dynamodb.Table(this, "Orders", {
  partitionKey: { name: "id", type: dynamodb.AttributeType.STRING },
  billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
});

const fn = new nodejs.NodejsFunction(this, "GetOrders", {
  entry: "src/handlers/get-orders.ts",
  runtime: lambda.Runtime.NODEJS_20_X,
  environment: { TABLE_NAME: table.tableName },
  bundling: { minify: true, sourceMap: true },
});

table.grantReadData(fn);

const api = new apigateway.HttpApi(this, "Api");
api.addRoutes({
  path: "/orders",
  methods: [apigateway.HttpMethod.GET],
  integration: new HttpLambdaIntegration("GetOrdersIntegration", fn),
});

That’s just the infrastructure. You still need the handler file, the stack wiring, the app entry point, and cdk deploy with CloudFormation.

With effortless-aws, the same thing is:

// That's it. One file.
import { defineApi, defineTable } from "effortless-aws";

export const orders = defineTable({
  pk: "id",
});

export const api = defineApi({
  basePath: "/orders",
  deps: () => ({ orders }),
})
  .setup(({ deps }) => ({ orders: deps.orders }))
  .get("/", async ({ orders }) => {
    const items = await orders.scan();
    return { status: 200, body: items };
  });

Run eff deploy. Done. The table, the function, the route, the IAM permissions — all created in seconds.

How It Works

Under the hood, eff deploy goes through four stages. Orchestrating them was the hardest part of the project — each stage feeds into the next, errors can happen anywhere, and resources depend on each other. Effect-TS made this manageable: the whole pipeline is composable, each step is an Effect you can reason about independently.

1. Scan

ts-morph reads your TypeScript source and extracts every defineApi / defineTable call — basePath, routes, deps, config, static files — straight from the AST. This was the part where I realized metaprogramming in TypeScript is actually viable. Instead of maintaining separate YAML or JSON config files, the code itself is the source of truth. ts-morph made it surprisingly elegant.

2. Bundle

esbuild compiles each handler into a single ESM file. I had experience with esbuild before — it’s fast and does its job well. But I also wanted to solve the dependency problem: in a project with many Lambda functions, they usually share the same production dependencies. Bundling node_modules into every handler ZIP felt wasteful. So I put shared dependencies into a Lambda Layer — one layer for the whole project. Each handler bundles into a clean single JS file, and the layer provides node_modules at runtime. This was its own challenge to get right, but it works reliably — at least with pnpm projects so far.

3. Diff

The tool checks what already exists in AWS and compares it with what your code declares. Only the differences get applied. This is essentially what CloudFormation does — syncing desired state with current state — but without the provisioning engine overhead. Getting this right was the biggest conceptual challenge: figuring out the right granularity of comparison and making sure updates are idempotent.

4. Deploy

Direct AWS SDK calls create, update, or reconfigure resources — Lambda functions, DynamoDB tables, API Gateway routes, IAM policies. Because every AWS call goes through the typed Effect wrappers, every possible error is known. If a function already exists — I log it and move on. If there’s an internal AWS error — I stop the deploy. No guesswork, no catch-all try/catch blocks.

Try It Out

effortless-aws is currently in alpha. It works — I’m using it myself to deploy real projects: the documentation website, and a couple of personal projects that use Lambda functions, DynamoDB tables, streams, and triggers. Everything deploys and runs. But it’s still in active development: there may be rough edges, and I’m constantly testing and fixing things.

The roadmap is full of features I want to add, and the project is evolving fast. I’ve put together a website with documentation that covers what’s available today — handlers for Lambda functions, DynamoDB tables, static websites, and more.

npm install effortless-aws

Tools I used to build this:

Effect-TS — typed functional programming for TypeScript
ts-morph — TypeScript AST analysis and manipulation
esbuild — fast JavaScript/TypeScript bundler
AWS SDK for JavaScript — official AWS SDK v3
Typed AWS SDK wrapper — Effect wrappers with typed errors for AWS SDK

I’m confident in the ideas behind this project and I’ll keep building it. If you’re a developer who wants to ship faster — to spend your time solving real problems instead of writing infrastructure config — give it a look. I’d love your feedback.

Best use of LLMs isn't code

Wed, 01 Apr 2026 20:18:36 GMT

The best use of LLMs has nothing to do with code.

I’ll be honest — I don’t love the hype around LLMs. And yes, I know it sounds tedious to remind people that an LLM is not intelligence. It’s a language model trained on a massive amount of data. But I think it matters to keep saying it.

Here’s what actually changed for me.

The real problem

I’ve always had more ideas than time. Side projects, libraries, architectural experiments — things I wanted to explore but couldn’t justify spending weekends on. They just sat there, accumulating.

LLMs didn’t magically turn those ideas into products. They didn’t write production code for me. They didn’t “solve” anything.

What they did: they gave me someone to think with.

Brainstorming at 2 AM

I could take a half-formed idea and brainstorm it. Poke holes in it. Explore adjacent solutions. Ask “what if” without committing hours to a prototype.

Some ideas I threw away — and that’s valuable too. Some I shaped into concrete libraries and tools.

I once read that ideas should be shared, not hoarded. That you grow them by discussing them openly. LLMs became that for me — a thinking partner available at 2 AM when the idea won’t let you sleep.

A caveat

LLMs are biased. Without clear instructions and constraints, they can confidently lead you in the wrong direction. You should never trust what comes back on the first iteration.

But here’s the thing — that’s exactly why brainstorming with them works. You’re not asking for answers. You’re asking for angles. The output isn’t the point. The thinking it triggers in your head is.

I used to think I understood system design, architecture, distributed systems. I worked with these things — but working with something and truly understanding it are not the same. Brainstorming with an LLM exposed the gaps I didn’t know I had. It broke my illusion of understanding and replaced it with something real.

What most people miss

The real power isn’t vibe-coding. It’s not “look, it wrote a React app.” It’s iteration.

Building anything meaningful — a startup, a product, a career — is the result of thousands of iterations. You think, you try, you fail, you learn, you refine.

LLMs compress that loop. They let you iterate on the idea itself before you write a single line of code — stress-test it, find angles you hadn’t considered, discover where it connects to something bigger.

What I learned

That’s not artificial intelligence. That’s a damn good tool.

Hiring without feedback is broken

Mon, 30 Mar 2026 20:31:09 GMT

I pass every screening call. I answer every technical question. Then I get rejected — and nobody tells me why.

The pattern is always the same. Screening goes well — experience aligns, good conversation, we move forward. Technical round — databases, architecture, system design. Nothing that makes me pause. I answer everything.

Then — a week of silence. And either a polite “we went with someone closer to our stack,” or nothing at all.

You can’t debug a process that returns no error message.

The strange part

The technical questions rarely have anything to do with the actual position. Generic architecture topics. Surface-level database questions. Nothing that tests how I’d solve their specific problems or work with their stack.

It feels like many interviewers don’t have a plan. No rubric, no structure — just a conversation with some technical vocabulary sprinkled in. And if the questions don’t meaningfully filter candidates by skill, then what are they actually filtering by?

I think a lot of technical interviews are cultural fit assessments disguised as technical ones. The questions are easy enough that most experienced engineers will answer them. The real evaluation is happening somewhere else — tone, energy, how you communicate. But nobody says that out loud.

Why it matters

If that’s what you’re evaluating — own it. Call it a culture interview. Set expectations. Let candidates show up as themselves instead of preparing for a technical deep dive that never comes.

Because right now, you’re rejecting people and they have no idea what they got wrong. Not because the feedback is missing — but because the criteria were never on the table.

That’s not a hiring process. That’s a guessing game.

Automate your resume, don't write it

Sat, 28 Mar 2026 21:12:26 GMT

You don’t need to write a resume.

Every time I sat down to update mine, something felt off.

Not “I don’t know what to write” off. More like — this process doesn’t make sense. I’m an engineer. I think in steps, I build systems, I debug things. But writing a resume? I was just rearranging bullet points, hoping the order would somehow matter.

No clear path. No way to verify the result. Just gut feeling and formatting choices. And don’t even get me started on templates — Awesome CV or minimalist? One column or two? Every choice feels arbitrary, and none of them change what you actually have to say.

It always bugged me. And it took me a while to figure out why.

The insight

A resume is a build artifact. It’s compiled output — not source code. I’d been editing the build this whole time. That’s like patching minified JavaScript instead of fixing the original TypeScript module. No wonder it felt off.

So I wrote the source

I created a source file for my career — a markdown document where I wrote down everything. Every job: what I did, why I joined, why I left, what I’m proud of, what was hard. No formatting, no optimization. Just the facts.

Funny thing — that’s exactly what recruiters dig for in screening calls. Your motivations, your transitions, the context behind the bullet points. Except now it exists as a document before the call even happens.

Why markdown

Markdown is plain text — it’s readable by humans and by LLMs equally well. Once your career is in a structured markdown file, generating a resume becomes a pipeline: feed the source to an LLM, get a content plan tailored to the role, then render to PDF. The creative part is already done — the rest is mechanics.

Applying for a backend role? The LLM pulls your system design work, infrastructure experience, performance wins. Fullstack position? It shifts the weight toward product delivery and cross-stack ownership. Cover letter? Same source, different output format.

One source file. Multiple builds. Each one tailored — without rewriting anything by hand.

I committed mine to a git repo. Versioned. I never have to remember what I did 5 years ago — I just read the file.

The resume stopped feeling weird once I stopped treating it as something I write. It’s something I generate.

There are dozens of resume builders out there — paid and free. They solve the formatting problem. But none of them solve the real one: where do you store the context that never fits in a resume? The reasons you joined. The reasons you left. What you actually learned vs what the bullet point says.

How do you keep that information alive?

From 85% rejections to interviews

Tue, 24 Mar 2026 23:14:19 GMT

I kept getting rejected — and I couldn’t figure out why.

Job searching is hard. Remote job searching is harder by an order of magnitude. I was sending out 30 applications in a couple of days. Getting 25 auto-rejections back. My experience was relevant, my skills were real.

Then I realized: the problem wasn’t my resume. It was my process.

What was actually happening

I’d see a position that looked like a fit. Apply. Move on to the next one. No deep analysis, no second look. Just volume.

But “looks like a fit” hides a lot of traps. Buried in a wall of keywords — hybrid required. On-site in a country I’m not in. “Fluent in X” where X is a technology I’d need months to ramp up on. Easy to miss when you’re skimming 20 listings a day.

I wasn’t getting rejected because I was unqualified. I was getting rejected because I was careless.

The problem with job listings

Let’s be honest — most job descriptions are unreadable. Companies dump massive walls of keywords, mix hard requirements with nice-to-haves, bury the actual deal-breakers somewhere in paragraph four. Reading 20 of these a day is draining, and the more you read, the less you actually see.

So I built a system

I’m building a platform for myself — think of it like a shopping cart, but for job vacancies.

I browse jobs as usual, and when something catches my eye, I save it through a Chrome extension. The extension grabs the page content directly from the DOM — no copy-pasting, no reformatting. The raw listing goes into my personal database.

From there, an LLM parses the vacancy — extracting hard skills, soft skills, location requirements, work format, deal-breakers. All the things a human eye skips over when scanning fast. It turns a wall of text into a structured breakdown I can actually reason about.

Before I apply, I sit with the parsed result. Do I actually want this? Does it match what I’m looking for? Is there a hidden requirement that disqualifies me?

It’s a simple shift: instead of apply-first-think-later, I think first and only apply when it makes sense.

The result?

Instead of 30 applications and 25 auto-rejections, I send 5 and get 2–3 screening interviews.

Same resume. Same experience. Fewer applications. Better outcomes.

What I learned

Maybe the hiring system isn’t broken. It’s just more complex than it used to be. And spraying applications into the void doesn’t work — not because the system is unfair, but because it rewards precision.

The vacancy comes first. Study what’s actually required. Then decide if it’s worth applying.

It turns out the bottleneck was never my resume. It was whether I was applying to the right positions in the first place.

The generalist's hiring problem

Mon, 16 Mar 2026 21:44:23 GMT

I know too many things. Apparently that’s a problem.

I started with PHP. Then spent years in the JVM world — Scala, Java, building distributed systems. Did backend, DevOps, CI/CD, built frontends with React and Vue. Now I’m deep into TypeScript, serverless, and cloud infrastructure.

I could pick up Go or Python on any project — learning new tools has never been the hard part. The hard part is convincing someone to let you in the door.

But try explaining that to an ATS.

What actually happens

You find a great position. You read the description and think — I’ve done this. The architecture, the scale, the kind of problems they’re solving. You’ve been there. Maybe not in this exact language, but you know how to build this.

But the listing says “Go required.” Your last two years say TypeScript. You apply anyway. You don’t get the call.

I get it — recruiters have 200 resumes to review. They need filters. But the filters are keyword-shaped, and people aren’t.

I think the system rewards narrow specialists and punishes curiosity.

You’re either “a Go developer” or “a React developer.” If you’re both — you’re neither. And if you’ve been five things over fifteen years — good luck fitting that into a keyword match.

The irony is — the best engineers I’ve worked with were exactly like this. Curious, cross-functional, able to jump between layers of the stack. But that profile doesn’t survive a 6-second resume scan.

I can’t change the system. But I can engineer my way around it. That’s exactly what I’m building.