The Year Was realfast

one year as the first Forward Deployed Engineer at realfast

A year ago, if you'd handed me a hard problem, I'd have tried to build the best possible thing in one shot. Get it right the first time. That instinct felt like competence.

Then I joined realfast as its first FDE — and walked into a world that punishes one-shot thinking.

A Forward Deployed Engineer sits at the seam between the product and the customer. You don't ship features into a backlog and walk away — you embed with the people who'll actually use the thing, find the real problem, build it, and stand next to them when it goes live. I was the first one hired here, so a lot of the first year was also figuring out what the role even is. But the very first thing it taught me had nothing to do with the title. It was that getting it right on the first try is the wrong goal.

The tokenmaxxing day

I felt it in my first month.

I joined in June 2025. We had Claude Code access — credits only, no subscriptions back then, just a meter quietly ticking on every prompt — and the brief was about as short as it gets: go build. You were handed the keys from day one and trusted to drive.

Small features were easy. The depth was where it got hard. One of the first real things I had to ship was a state machine for a ticketing system — the whole thing, a ticket moving from its first state all the way to its last. The problem was I'd never built a state machine before. Not like this. I had a plan and a rough picture of what the states should look like, but that's not the same as having done it.

So I tried. It failed. I tried again. Failed again. I tried a third time — and it worked. All in a single day. By the time I cracked it, I'd burned roughly $120 of API credits.

Yes, we were tokenmaxxing since day 1.

It felt reckless — $120 to get one state machine working. But that day is exactly what compounded into everything I build now. Not because the models were good (they've gotten far better since), but because three fast, cheap failures in an afternoon taught me more about how and what to build than a week of getting it right slowly ever would have. The one-shot instinct died right there, and good riddance.

But fast isn't the same as right

Failing fast is cheap and it's fast. It is not, on its own, enough.

The SaaS world I came from is product-centric — even with "service" in the name, the instinct is to anchor to the roadmap: here's what we built, go use it. In an IT services company that breaks instantly. An enterprise customer doesn't care about your product. They care about their problem, and whether you moved a number that matters to them.

Sidu put words to the thing I'd been half-feeling. Before you build a feature, he says, ask whether it moves a metric for your customer. If it doesn't, go back to the problem statement, find the metric, then come back. And if it does move a metric, ask the second question: does that metric move revenue for me? If you can't answer both, you don't build it.

I'd always known "the customer asked for it" was a bad reason to build something. What I didn't have was the why. Now I do — and in a services company, where the business team that hired you is watching whether you're a competent delivery team, it's everything. Fast failure points you at a solution. The metric tells you it's the right one.

The wall AI couldn't fake past

Then I hit something neither speed nor a good question could get me through.

A few months in, I got onboarded to a client project in a financial domain — completely new to me. By then I'd spent something like seven months building almost entirely with AI, and I'd gotten used to a certain pace. But you can't prompt your way past not understanding the domain. The model just keeps agreeing with you — "You're absolutely right!" — and when you don't know the space, that agreement is worthless. It can't tell you what you don't know to ask.

There was a deadline pushing from the other side, too. So I did the unglamorous thing: sat down with the docs and actually learned it, broke it into pieces, moulded the understanding as fast as I could. I didn't fail it. But it was the moment that made the lesson concrete — the tool accelerates you; it does not excuse you from the work.

The people were teaching this all along

Here's what I only saw in hindsight: the thing AI forced on me — fundamentals first, the slow work the tool can't do — was exactly what the people around me had been drilling from day one.

realfast is a ~50-person company, and the thing I vouch for most isn't the tech or the depth of knowledge, though both are real. It's the people. You always walk away having learned something.

Rajnish, our VP of Engineering. I worked with him briefly on Manazer, one of our internal tools — the first time I was writing real production code, in Ruby on Rails. I'd been trying to learn Ruby on and off for years (no agents back then), and he reframed the whole thing: don't just grind the basics — the fundamentals are roughly the same across languages anyway. Take a problem, make sure you can get hold of a solution, try to implement it, look at the solution, implement it again — and run that loop until you can do it cold. That builds the muscle. I later realized it was the same idea baked into the bootcamp I went to in May 2026.

Prashant, our Principal Engineer, leads the delivery project I'm on. Fundamentals first — don't leap to the big problem before you've got the basics — and then, once you're through, he turns it around: okay, now how does this scale? That combination is rare. When I was trying to work out whether I was even heading in the right direction, he told me to write — that writing forces you to articulate better. This blog is my first real jab at taking that advice.

There are more people I could go on about. They deserve their own post.

The same instinct, everywhere

Once it clicked, the build-from-blocks instinct started showing up in places that had nothing to do with that first state machine.

At the keyboard it became parallelization — what I keep calling "writing with both hands." I'll have two different hunches about how to solve one bug; instead of betting on one, I open two Claude sessions side by side, point them at the same bug with different prompts, and run them at once to see which approach wins. One problem, two mindsets, simultaneously. Till then I couldn't write with both my hands. Now I can.

And then the same instinct turned up off-screen — not as speed this time, but as patience. Running agents generates a staggering amount of text: plans, diffs, reasoning, logs. Run two at once and you've doubled it. None of it does you any good unless you actually read it — you can't trust output you only skimmed. Somewhere in all that reading, the job quietly turned me into a reader.

And it didn't stop at work. I'm not a natural reader. Outside of curriculum books I'd finished exactly two — The Mom Test and Dream With Your Eyes Open — and each took me two to three years. This past month I got through The Goal and The Pragmatic Programmer, with more lined up. Blogs I'd done before, but books are different; you don't get the depth from a blog. A book makes you go on a journey — even a ten-page booklet asks you to be patient enough to sit inside it and put your own understanding in.

There's an irony I can't get over. The paper that started all of this is called "Attention Is All You Need" — and meanwhile Instagram and reels have walked off with all of ours. God save our attention spans. Sitting down with a book now feels almost subversive: giving one long thing your full attention, when everything else is built to split it. Same muscle as the work — start from the fundamentals, don't rush the one-shot answer. It turns out that mindset doesn't stay on-screen.

A year in, and more to come

So a year in, I no longer one-shot. I start from the building blocks and let it compound — and I owe a lot of that to AI, because without the freedom to experiment and fail that cheaply, I'm not sure I'd ever have turned in this direction.

What I'm most curious about for year two is bigger than realfast. We've more or less solved for agents — so how do we scale AI until it slides into everyone's life the way the calculator did? People feared calculators would take jobs; instead they just made us faster and quietly became a default, tucked inside every system you touch. AI gets there too, and the unlock is cost — cheap enough to disappear into habit. And serving enterprise customers, that's the job: not a flashy agent bolted on the side, but AI woven in invisibly, until it's just how the system works and nobody thinks about it.

On a personal note — AI now does a part of my job. Energy can neither be created nor destroyed, so it has to go somewhere. I'm putting mine into writing more online, revisiting photography, and trying new side quests. This is the start of that.

And if you've been patient and read this far, you're either a reader, or you'd like to work at realfast — or you're an AI agent. If it's the first: thank you, genuinely; stick around, there's more coming. And if it's the second: we're hiring. If any of this sounded like the way you want to work, come build with us.