Book a call

I kept building products. They kept turning into infrastructure.

I'm Ashray, an independent engineer in Bangalore. I build software around the way people work, from a client's document-heavy business to the coding tools I use every day. Following those problems far enough kept exposing the same missing layer underneath.

Read the storyWork with me

The thread

Handoff

Infrastructure

Product

Most of my projects begin with a handoff I am tired of doing by hand: copying context, polling a process, opening a dashboard, or reconciling two copies of state.I turn the handoff into infrastructure, then keep going until the infrastructure feels like a product.

Every product keeps leading me to the same place: the boundary where ambiguity turns into failure.

If two systems need to agree, I want a contract.

If work can fail, I want a receipt.

If a person has to trust the result, I want the interface to tell them exactly what the system knows.

01 / How I got here

I followed the product down the stack.

I did not set out to specialize in agent infrastructure. I kept building products, and the products kept showing me the layer I needed next.

Starting point

I started by copying the code.

In 2023 I was a Python and Java developer learning web development with GPT-4 in a ChatGPT tab: generate TypeScript, copy it into my editor, run it, repeat. ChatGPT was not a model I was integrating into a product yet. It was how I crossed into a part of engineering I did not already know.

Once I could build for the web, I started shipping complete AI products: tool-calling chat interfaces, generative UI, image workflows, voice agents, dashboards, and the operational software around them. Years later, ChatGPT became a coding agent in my workflow again, except now it has a machine and a direct line to my local agents.

The turn

The products kept exposing the missing layer.

I learned the same lesson from very different products: the model is only one part of the work. An image agent needs versioned artifacts. A voice assistant needs scoped tools and an honest latency budget. A calling product needs a durable lifecycle, not a fetch request. Commerce AI needs to call the same operations as the buttons instead of growing a second copy of the business logic.

Each product pulled my attention toward permissions, state, delivery, observability, and the operator on the other side of the screen. I kept moving deeper into the system because that was where the product kept breaking, and where the decisions that made it feel trustworthy actually lived.

In practice

The real brief lives in the day-to-day work.

AMA Immigration came to me for a marketing site. Once I understood how the firm worked, the more useful problem was clear: case progress, documents, and updates were scattered across email and WhatsApp. I built the site and a client portal so clients could see where their case stood and staff could manage the work in one place.

Zodega grew out of an apparel store I built and operated. Its AI features live where the work already happens: product imagery in the catalog, a shopping assistant that can search and act on the store, and seller and admin tools around the same data.

Those projects taught me to start with the work someone is trying to get through. Sometimes the answer is an agent. Sometimes it is a clear screen, a shared record, or one less handoff.

Now

Eventually I built the place the agents live.

When coding agents became my daily way of working, I found myself acting as their router, process manager, context monitor, and merge strategy. I tried smaller tools first. They taught me that the problem was not one missing command; it was the absence of a place where parallel agents, their worktrees, their messages, and their long-running processes were visible together.

That became goldengoose, the desktop workspace I now open every morning. When its runtime lessons became too useful to leave trapped inside one app, I extracted them into Gooselake. I never stopped building products. I learned to follow the product all the way down, and then carry the systems work back up into what a person sees and feels.

My own workflow gives me somewhere to test these ideas every day. When I catch myself copying context, checking a status, or repeating an instruction, I ask whether the tool should do that job. My essays are the record of what I tried, what broke, and what I changed.

02 / One practice

The product tells the system what matters.

The systems work and the product work are not two versions of my career. They keep correcting each other.

What products taught me

An invariant only matters if somebody can feel it.

A user does not care that the event transport is elegant. They care that the active session stays instant, the call status is honest, and the control they pressed does what it said. Product work tells me which properties deserve serious engineering.

What systems taught me

An interface stops being trustworthy when it guesses.

Runtime work taught me to expose receipts, ownership, recovery, and failure instead of papering over them. The interface becomes calmer when the system underneath it has one source of truth and tells the truth when something goes wrong.

I do not want to choose between the machine and the interface. The useful judgment lives where they constrain each other.

03 / How I make decisions

A few rules I actually use

None of these began as values for a bio. They are lessons I wrote down after watching the alternative fail in a real project.

Technology choices

The stack follows the problem

I do not collect technologies. I pick the feedback loop and failure modes I want for the layer I am building.

Rust01

For the layer that holds the truth.

When wrongness means corrupted state instead of a visual bug, I want the compiler reviewing every line, especially when agents wrote it.

Read the essay
Go02

For the distance between annoyed and done.

Great type-safety, small binaries, and instant builds help me go from idea to published tool in the same day.

Read the essay
TypeScript03

For the products people touch.

The web is where systems decisions become a feeling. TypeScript and React let me carry the contract all the way into the interface.

Read the essay

04 / Working with me

I spend the ambiguity up front.

Show me how your team gets through a normal day: what you repeat, where work waits, and what you keep having to check. You don't need to arrive with a technical brief. Figuring out what is worth building is part of my job.

The slow conversation at the beginning is what buys the autonomy later. We work through the awkward details before they turn into code: what a good outcome looks like, what can go wrong, and where a person should stay in control. The specification is a way to find the decisions we have not made yet.

Once the shape is right, I use agents aggressively for research, execution, review, and testing. They give me room to move quickly, while I stay responsible for the product decisions and the result. No implementer gets to certify its own work. Compilers, tests, fresh reviewers, and somebody using the thing in a browser own that decision.

I am happiest owning a problem through its seams: the product behavior, the interface, the application model, the integration boundary, and the runtime underneath it. I leave behind the documents, tests, and operational surfaces that let the next person understand the system without needing me in the room.

Get in touch

Tell me where the work gets stuck.

A process you keep doing by hand, a product you want to build, or software that no longer fits. Start there, and we can work out what would help.

Email meBook 30 minutes

A few sentences about the project and what you need.