Hi there, I'm Manoj.

A Senior fullstack & AI engineer.

learning, failing, re-learning, writing, and shipping

I've been writing code and building things for over twenty five years now. I still get unreasonably excited when something deploys clean on the first try. And yes, I still hunt and fix bugs — AI generated or otherwise.

These days I describe what I do as AI systems architecture, engineering, and technical partnership. A fancy way of saying that I help founders, like you, build production systems that actually work. I do this by using AI where it helps, and good engineering everywhere else. I sit in the gap between "we asked Claude to write our entire codebase" and "we need to hire a CTO." If that gap sounds familiar, we should talk.

By day, I work at lemlist on Taplio and TweetHunter. Keeping the social media automation products running. That means pocs, features, architecture, workflow reliability, and data pipelines. The stack is GCP Cloud Functions, Firestore, Queues, Tasks, Node.js, React, and Next.js. I've spent close to five years doing exactly this. For the last year or so, AI has been a serious part of how I write, and ship code; at lemlist, and everywhere else. And currently, the real work is making AI-engineered features, fixes, and code hold up in production. Our's is a small team: six developers, at the time of writing this.

Outside of work, I build small software, apps & utilities for the Apple eco-system, micro-SaaS experiments, and tools. Things that should exist but nobody’s gotten around to making yet. Right now that means a macOS menu bar app, a series of newsletters, web apps and so on. I also believe that sometimes you just need to build something that has no business model and see what happens. (Something happened. People seem to like getting a koan with their morning coffee.)

AI & Code

What I actually believe about AI and engineering

Trillions. Trillions of dollars, and tokens are being converted into code.

Everyone is using AI to generate code, features, and entire products - SaaS apps or otherwise.

The hard part was, and is not the generation & one-of releases. It is the continous execution, maintainence, and debugging of the generated code. Once the generated output hits production, requirements may shift. Or edge cases surface. Situations come up; like nobody on the team understands the architecture well enough to debug it or maintain it. That’s where most AI-assisted projects quietly fall apart. The hard part is what happens after the initial excitement of deployed generation wears off.

My job is to make sure yours doesn’t. I design the boundaries, enforce the state, build the observability. Making sure the system keeps working from behind the scenes.

I’m here to solve those problems, so you can focus on building the next big thing. Without worrying about the technical debt that comes with it.

Repeated execution beats fast generation, mvps, and prototypes. Everytime.

That's what I bring to the table.

Experience, Skills & Lessons

The twenty-five-years version

with 25+ years of experience building software & production systems.

I’ve launched my own ideas and startups. One worked, the others didn’t. I’ve worked across startups, agencies, and established companies. The full gamut and spectrum include teaching as a professor, shipping for banks, shipping for corporations, solo shipping, shipping in teams, leading projects, etc. I’ve written production code in TypeScript, Ruby, PHP, Objective C, Java, .net, Perl, Python, Go, and Rust.

After all these successes, and failures what remains is a lot of scar tissue. Along with important lessons & skills. Lessons about what actually matters when you’re building something. Skills to navigate and adapt to the ever-changing landscape of software development. Along with adapting to ever-changing landscape of reality & the landscape of people. I’ve learned the hard way that interesting ideas, and the viable products are often different things. I’m getting better at telling them apart. Most of the time, and am still experimenting with how to best navigate that tension.

Some lessons learnt: discipline & showing up on time. Knowing when to stop adding features and start fixing the ones you have. Above all, it is knowing when to pivot, stop, say no, and let go.

Some skills acquired: learning operations, pipelines, processes. learning how to learn, learning how to teach, learning how to lead, learning how to follow, learning how to ship, and learning how to clean up after.

As far as shipping code is concerned, the through-line is, and has always been the same. Make the system work. Make it stay working. Make it understandable - to your future self, 6 months down the line, and to the next person who touches it.

My daily drivers are Neovim, Zed, XCode, & VSCode - each with its own use-case. PNPM, pyenv, virtualenv, rbenv. Bear, organized with a custom Johnny Decimal taxonomy setup. I will absolutely tell you about if you make the mistake of asking. I reach for simplicity, stability, and maintainability. Check out colophon here.

I like experimentation, and am generally up for trying new things. Anything that can make things simpler, easier, and more manageable. Abstractions are magic, and magic does simplify.

Engineering philosophy

What I value in code

Clean & simple architectures.
Stable, maintainable systems.
Readable, repairable code.
Value over volume.

Operating preferences

How I work

Break ambition into achievable, small scopes.
Trade-offs are welcome; for stability & maintainability.
Reduce friction in code.
Simplicity is the goal.

Who?

The rest of me

The disconnect between the engineering and the non-engineering parts

There’s a whole other side to what I do that does find itself on this site. I keep a separate creative identity at @indefiniteloop. Photography, film, cinemagraphs, tea rituals, and the kind of philosophical observation that probably makes me insufferable at parties but keeps me sane at a keyboard.

Somethings engrained, in no particlar order: Zen philosophy, minimalism, and the discipline of choosing fewer things further. Journaling. Experimenting with personal knowledge systems. Using tools to shape attention (which is either a profound statement or an occupational hazard depending on your perspective).

Those and other hobbies are not built upon my engineering career. They’re the reason I build the way I build. Often exposing constraints, restraints, sense, and much overlooked choices. These come into their full play when experimenting, and discarding. And are layered with strong opinions about structures, and architectures. That with a deep suspicion of anything that optimizes for engagement over usefulness.

To now, then, and beyond

What I’m building toward

A body of work that holds together. Leaves small footprints. Footprints in the form of expired products, opensource projects, writing, useful tools, and small apps.

The goal is not just to make things. The goal is to make things that remain worth having, experimenting with, discarding.

Things that carry a little joy, a little peace, and a little value.

ready? go!

Work with me

let me help you build something useful, durable, and clear.

I take on a small number of technical partnerships outside of my day job. If your product has outgrown vibe coding. And you find yourself in of need someone who can ship, maintain and scale. Or integrate AI into production workflows. Or just be the senior engineer in Slack who brings clarity and momemtum, then that’s exactly the work I do.

Niether equity talk, nor three-month onboarding. Just value, code, and shipping.

Work Together → Read the Writing