I Asked for a Resource. He Saw Something Else.

Early 2024. I was not looking for a co-founder.

That is not false modesty. It was a calculated position.

I had just come through three months of genuine doubt. Out of money. Uncertain whether two and a half years of building still meant anything in a world that had pivoted entirely to AI. I had made the decision to carry forward, collected money from friends and family to keep going, and was now looking for one thing: a paid technical resource who could take over from the interns, bring proper engineering discipline to what we had built, and help me get to a product that was ready for real users.

A co-founder was a different ask entirely. A co-founder meant equity. It meant belief. It meant someone choosing to bet on a non-technical founder with no revenue, no users, and a proof of concept that worked but looked nothing like a market-ready product. I was not sure I was in a position to make that ask. So I did not make it.

I looked for someone who could do the job. Through an introduction from a former colleague, I met Mihir Sanchala.

What I Walked Into That First Meeting

I talked for a long time. About integrations, workflows, cloud costs, analytics dependency, engineering bottlenecks. No AI disruption narrative. No grand vision framing. Just the actual execution pain I had watched teams struggle with for years and what the platform was trying to do about it.

Then I showed him the codebase. Flask backend. React frontend. Two interns. Architectural gaps, scalability concerns, shortcuts: everything you normally expect when interns are building an early system under constraints. I knew it needed serious work. I was not pretending otherwise.

What I noticed was how he asked questions. Not the polite questions you get from someone going through the motions of due diligence. Specific ones. About the data flow between modules. About what happened at scale. About decisions the interns had made that I could not fully explain because I had not made them myself. He was not testing me. He was genuinely trying to understand how far the thinking had gone.

He left without committing to anything. I did not know what to make of it.

Within a week he came back and told me he was not interested in being a paid resource. He wanted to invest. He wanted to come in as co-founder.

I said yes immediately. Not because I had been waiting for it. Because when it happened it was obviously right.

What Mihir Told Me About the Years Before

Mihir had spent years doing technically solid work across different companies. Data movement, infrastructure scaling, workflow management. He was good at it. But at some point he started noticing something that could not be unseen.

Every company he worked with had a slightly different tool stack and an almost identical set of problems. One used Airflow, another had custom scripts, someone had Tableau, someone had Superset. Did not matter. Everyone was spending enormous engineering effort just keeping systems connected. The tools changed. The pain did not. The 2024 MuleSoft Connectivity Benchmark Report found that the average enterprise manages over 900 applications — and only 28% of them are integrated (MuleSoft, 2024 Connectivity Benchmark Report, 2024).

There was one project he described to me that has stayed with me since. Four months building a pipeline just to move data from one internal system to another so a business team could finally see it in a dashboard. Multiple developers. Cloud infrastructure. Custom scripts. When it was finally done, someone from the business side asked if they could add one more data source.

They started the whole thing again.

He had always wanted to build something of his own. But he had no clear plan about when that would happen. Then the introduction came through. What he was told before the meeting: this person is strong on the business and product side and has already built something. His honest reaction, as he described it to me later, was straightforward. He had heard that before. Usually it meant a few screens, a pitch deck, and a very large vision with very little actually working.

He walked in expecting a half-baked idea with a decent presentation layer around it. He did not expect much.

What He Saw That I Could Not

What Mihir told me later was that the conversation surprised him. Not the vision. The specificity. No buzzwords, no disruption framing, just actual execution pain that he had personally watched teams struggle with for years. For the first time he felt someone was trying to reduce complexity instead of adding another layer to it.

The codebase confirmed his fears. It needed serious work and he knew it immediately. But what stayed with him was not the code quality. He had seen startups with far cleaner codebases and zero product understanding. Here it was the opposite. Someone had built a working proof of concept not because they understood engineering deeply but because they understood the problem deeply. That is a rarer thing.

The safer option for him was obvious. Take the consulting money, guide the technical direction, keep distance from the risk.

What shifted things was a conversation I arranged that week with my mentor, the former colleague who had been my sounding board through the entire build, by then in senior engineering leadership at a well-funded AI fintech. I wanted him to pressure-test Mihir the way he had pressure-tested the idea three years earlier.

Mihir told me later he was nervous going in. Because if he was being honest with himself, he had never built a full Python product before. Mostly scripts, automation, utilities. Not a complete platform.

The conversation went well. And something changed for him after it. His words: maybe I had been underestimating myself.

That week was confusing by his own account. But somewhere he knew that if he stayed external he would eventually regret not taking the chance. He had personally lived the problems Edilitics was trying to solve across three different companies. He had watched teams spend money on infrastructure, developers, orchestration tools, dashboards, cloud scaling, and still struggle operationally. When he saw a platform trying to collapse that entire flow, he knew the problem was real. And he knew I was not going to stop building it.

He said yes. Not because of blind optimism. Because the problem was real and someone had refused to quit on it.

The Rebuild, the Runway, and What Changed

The rebuild through 2024 was foundational. Flask became FastAPI. Pandas became Polars. The security posture hardened properly. Integrations expanded to 22 live connectors. Everything the proof of concept had proved was possible got rebuilt to the standard a real product requires — from the data pipelines to the visualisation layer.

The months that followed were harder than the rebuild itself. Runway was low. Mihir's stable income from his previous engagement disappeared at exactly the point when personal financial responsibilities were still entirely real. EMIs. Family. Daily expenses that do not pause because a startup is burning through its last resources. We were doing consultancy work at night to extend runway. Borrowing money to keep going. Managing infrastructure credits carefully to avoid costs we could not absorb. There were stretches where the question was not what to build next but whether we could afford to keep the lights on long enough to build anything at all.

Most people around Mihir were confused about why he had joined in the first place. From the outside it looked risky and unnecessary. He already had stable work available. He could have gone back to it any time. What they did not see, what nobody outside the company saw, was how close things came financially at certain points. Survival itself had become part of the execution strategy.

What I noticed over those months was a shift I had not anticipated. Edilitics stopped feeling like something Mihir was helping me build. It started feeling like something he was building too. The difference is subtle from the outside. From the inside it changes everything. The decisions feel different. The difficult months feel different. The reason to keep going feels different.

That shift is what carried the company through to where it is today.

Why the Product Exists in Its Current Form

In May 2026, Edilitics is a two-founder company. That feels obvious from the outside. From the inside it was never guaranteed.

There is a version of this story where Mihir takes the consulting engagement, does good work, and moves on. Where the product gets better but the architecture stays fragile. Where the foundation never gets built properly because nobody with the right depth was ever fully invested in getting it right.

That is not what happened. What happened is that Mihir walked into a room expecting a pitch deck, found a problem he had lived himself across three companies, looked past a codebase that needed serious work, and made a decision nobody asked him to make.

The product that exists today, the architecture that makes AskEdi possible, the encryption design that means your raw data never leaves your database, the semantic layer that gives the AI the context it needs to query correctly: none of it exists in its current form without what Mihir chose to build in 2024.

I asked for a resource. He saw something else. The product exists because he was right about what he saw.

Sources

MuleSoft. 2024 Connectivity Benchmark Report. Salesforce/MuleSoft, 2024. Retrieved May 2026. mulesoft.com