About
Who I am, and why I think about engineering the way I do.
I'm Ayush Dixit. I work as an engineering consultant — mostly with founders navigating architectural decisions they can't easily undo. This page isn't a résumé or a timeline. It's how I got here, how I make technical calls, and what collaboration actually looks like.
[01]
What Shaped My Thinking
A few projects changed how I approach problems more than any course or certification ever did.
My thinking shifted when I realised most technical problems aren't caused by technology — they're caused by unclear product decisions. Once the business question is fuzzy, every engineering choice downstream becomes a guess. I now treat clarity there as part of the job, not a prerequisite someone else should provide.
On a real estate platform, I watched the architecture need to evolve as the business model clarified. The first design wasn't necessarily wrong — it just wasn't finished. That taught me to build seams into systems early, so change doesn't require starting over.
Working at ThoughtSpot changed how I look at large systems. Individual features matter less than the boundaries between them — where data flows, who owns a domain, and what happens when one component changes without the others knowing.
Fiesta Liva was a lesson in simplification: the system got harder because we had kept complexity that wasn't earning its keep. Removing code and narrowing scope did more for reliability than any new abstraction would have.
A lead management project taught me that authorization isn't an implementation detail — it's a product decision. Getting access rules wrong erodes trust inside the product faster than most performance issues.
[02]
How I Make Technical Decisions
When the path forward isn't obvious, I come back to a few questions — not slogans.
Start with the business question
What problem are we solving, and for whom? I don't recommend stacks or patterns until that answer is specific enough to rule things out. Technology follows the problem — not the other way around.
Choose the simplest thing that fits
I look for the smallest architecture that still supports where the business is going — not the most flexible one I can imagine. Flexibility has a maintenance cost, and most teams pay it long after the person who wanted it has moved on.
Make trade-offs visible
Every decision closes doors. I try to name what we're giving up — speed, flexibility, operational burden — and write it down so the team six months from now understands why we chose this path.
[03]
How I Work
What collaboration looks like in practice — not a methodology deck.
01Understand the context first
We start with what you're building, what's constrained, and what can't break. I ask a lot of questions before I suggest anything — because recommendations without context are just preferences.
02Surface the decisions that matter
Not every choice deserves a workshop. I focus on the ones that are expensive to reverse — build vs buy, data ownership, deployment boundaries, team structure. Those get explicit trade-off discussion.
03Scope to the next milestone
I recommend what you need now, with a note on what triggers the next step. I'd rather document when to split a service than split it prematurely because growth might come.
04Leave the system explainable
Whether I'm writing code, reviewing architecture, or mentoring — the output should be something your team can extend without me. Decisions documented, boundaries clear, no hidden coupling.
[04]
What You Can Expect
Honest defaults for how I show up in an engagement.
Direct feedback
If I think an approach will cause problems later, I'll say so — even when it's not what you want to hear. I'd rather have an uncomfortable conversation early than debug a bad decision in production.
Maintenance over cleverness
Given the choice, I'll take the approach that's easier to change and easier to explain. Clever solutions tend to become someone else's burden.
One source of truth
When I see duplicated logic, divergent data models, or three ways to do the same thing — I push toward consolidation. Inconsistency compounds quietly.
Ownership through production
I'm not interested in handing off a design and walking away. If I'm involved in an architectural decision, I care that it actually works when deployed — not just that it looked correct in a diagram.