The fork

In third year of engineering, a few of us — Raj Thakur and I among them — ran a programming blog. Nothing ambitious: we did the lab programs everyone in a Maharashtra engineering college has to do, cleaned them up, explained them, and posted them. Classmates used it. Then people from other colleges used it. Then AdSense started paying, and for the first time something I'd written was earning money while I slept.

That was the seed, but not the decision. The decision came in M.Tech. By then we'd registered Solutions Touch and taken our first real project — an e-learning platform for a tuition class, in 2020, when COVID had just made "online" the only option a coaching class had. M.Tech required an internship. The normal path was to find a company, spend a few months there, and write a report. The other path was to walk into our HoD's office and say: we already have a company, let us intern at our own.

What I chose, and why

We walked in. The IT department put us into SGGS's incubation centre, gave us guidance, and gave us something better than guidance: B.Tech students as our interns. We were suddenly a company with a team, an office, and a client that mattered — the college itself.

We built the college's own website (sggs.ac.in) and a College MIS: the full student lifecycle, from admission through fees, attendance, examinations and results, digitised for the first time. When that ran, it was a reference. Colleges and schools in Nanded talk to each other, and over the next two years five to eight of them became clients on the strength of that one system.

The reasoning at the time was simpler than it sounds now. We'd already found that people paid for things we built. An internship would have taught me how someone else's company worked. Incubation let me find out whether ours could.

What it cost

M.Tech became a thing I did around the company rather than the other way round, and I didn't get the "see how a real firm works" internship that most of my batch did. I'd get that later, the long way.

What it gave

The technical foundation everything else stands on. A College MIS is a small ERP: the whole student lifecycle — admission, records, fees, attendance, examinations, results — in one database that a college runs its year on. It was the first system I built that other people's jobs depended on, and the first where being mostly correct wasn't acceptable. It's where I learned to design tables for a business process rather than for a screen, and to build a PHP/CodeIgniter codebase that interns could work in alongside me.

And the non-technical foundation: sitting across from college administrators explaining what the system would change for them, managing interns barely younger than me, and discovering that a reference from one working system is worth more than any marketing we could afford.

If you're at the same fork

If people are already paying you for something, you don't need permission to call it a company. You need a client who matters and a system that works. Get those, and the rest follows by reference.

The fork

By 2022 Solutions Touch had shipped 20+ applications — ERPs, exam systems, e-commerce, EMI collection — and I could build almost anything a client in Nanded asked for. That was the problem. Building was the only thing I could do. The company wasn't growing, and when I was honest about why, none of the reasons were about code.

I had no architecture-level experience. Every system was a CodeIgniter monolith with a MySQL database I designed on the spot, and it worked until the client grew. I had never sold a product properly — clients came by reference, not by a sales process. I had never managed a team beyond a couple of people I already knew. I had never presented to a management group, negotiated scope, or run a project with stakeholders who disagreed with each other. I'd been the founder, developer, support desk and accountant, and I was good at exactly one of those.

The fork: keep running a company on skills I didn't have, and hope to pick them up while surviving — or step out, work for someone who already had those skills, and learn them the way I'd learned to code: by doing them under someone better.

What I chose, and why

A job, but a specific kind. Not a large company, where I'd be a small part of a big process and see none of the whole. A startup, where a senior developer sits close enough to the founder, the client and the architecture to watch all three at once. Briidea was the first real option that fit: a fintech startup, small enough that I'd be in every conversation, in a domain — lending — where the business rules are unforgiving and the software has to be correct rather than merely working. I took it.

What it cost

Not much, honestly. I gave up running my own thing for a while, and Solutions Touch went from building to maintaining. It was the right call and it felt like one.

What it gave

Everything on the list I couldn't do in 2022, in two years.

Architecture: my first systems designed before they were built — a Loan Origination and Management System with configurable workflows across enquiry, application, verification, approval, disbursement, repayment and recovery; an eNACH mandate platform talking to bank APIs, where every mandate's state had to be correct no matter how the bank's side behaved; a legal recovery workflow with authority-, bank- and legal-team-level access. The stack moved from PHP/MySQL to Node.js, React, PostgreSQL, Flutter, .NET and WebSockets, and with it the idea that a schema is a contract, not a convenience.

The rest: my first client meetings where I wasn't also the vendor. Presenting to management. Formal communication with every stakeholder. Turning an idea into an implementation plan with other people's money and other people's deadlines. And informally leading six developers while my title still said Senior Developer — which taught me that leading is something you do before anyone gives you permission to.

If you're at the same fork

A founder who can only build is a developer with a heavier title. Go learn the rest from someone who has it. You can always start again — and next time you'll know what "everything" actually means.

The fork

At the end of 2024 I had two years of fintech behind me and a choice about what kind of engineer to be next. One path is the one most senior developers take: go deeper into the code, become the person who solves the hardest technical problem in the room, and let someone else own the plan. The other is to take responsibility for the whole system — the requirements, the architecture, the team, the delivery — and accept that your own code becomes a smaller share of the work.

SP IT Solutions offered the second: join as Team Lead on a Core Banking Solution for credit co-operative societies, a product that didn't exist yet.

What I chose, and why

I took it, because everything since college had been pointing here. At Solutions Touch I'd owned whole systems but small ones. At Briidea I'd learned architecture, stakeholders and informal leadership on systems that mattered. This was the first time both came together on something large: a banking product, from the first requirement conversation with a client to the first branch going live, with a team to build it.

I handled every phase as technical lead — requirement gathering with the societies, the service split and data design, the technology choices, the team's structure and standards, the delivery. Core banking doesn't forgive vagueness, so the design work was concrete from the start: which business areas became independent services and where the boundaries sat; PostgreSQL as the system of record with transactions designed around money, dates and interest; RabbitMQ for the work that shouldn't block a teller's request — notifications, background processing, event-driven flows between services; Redis for cache and short-lived state; Casbin for authorisation that has to know the difference between a Head Office user and a Branch Operator across every module, sub-module, action and branch. End-of-day processing, GL integration, deposits, loans, gold loans, shares — I worked on every module myself while owning how they fit together.

What it cost

Less of my day writing code, more of it deciding what gets written and by whom. I don't miss it as much as I expected to; the decisions turned out to be the interesting part.

What it gave

A product that is live at three to four societies, running their daily operations on a system I designed from the requirements up. A team of eight I lead. And a clearer definition of my own job: not the best developer on the team, but the person who makes sure the whole thing is right — and still reads every line that matters.

If you're at the same fork

Taking the lead role isn't leaving development. It's being accountable for all of it instead of some of it. If that sounds heavier, it is. It's also the first time the system is actually yours.

The fork

At Solutions Touch we launched BazaarTouch, an e-commerce marketplace for Nanded's local shops. The pitch was obvious: vendors list products, buyers buy. It went the way most obvious pitches go. Vendors didn't list. The few who did never updated stock, because keeping a live inventory is a full-time job for a shop that already has one. After months of zero orders, the vendor conversations turned from polite to awkward. The site is gone; even the domain has expired.

The real fork came after. Call it a failed experiment and move on — which is what I did for a while — or go back and understand why a Nanded shop and a Nanded buyer didn't want the thing I'd built for them.

What I chose, and why

The second, eventually. The mistake wasn't the market; it was that I'd copied Amazon's model onto a business that doesn't work like Amazon. A local shop doesn't need a cart. A local buyer doesn't want to check out online. What the buyer wants is to know before walking there whether the shop has it and what it costs. What the vendor is willing to do is answer that question — because they answer it fifty times a day already.

So AvailableIn.Store has no inventory table that a vendor maintains. The core object is an enquiry, not a product: customer asks, vendor replies "available, Rs. X" over WhatsApp, and the reply is the record. Every answered enquiry is written to the vendor's history, and the catalogue is derived from that history — what the shop usually has, at roughly what price — rather than entered. Stock is inferred from behaviour, never declared. If a vendor stops answering for an item, it fades from the catalogue on its own. BazaarTouch had a products table with a stock quantity column that a shopkeeper was supposed to keep true. That column was the whole failure.

What it cost

Months of building a product nobody used. Goodwill with shopkeepers I'd asked to trust me. And the harder cost: admitting that "we need to explain it to vendors better" was never the problem. They'd understood perfectly and said no.

What it gave

A product I'm building now with Raj Thakur, this time with what I didn't have in 2020 — not the ability to build, I had that, but the experience of what happens after building: sales, onboarding, automation, execution, the parts of a product that decide whether anyone uses it. And a rule I now apply at work, too: if the system's correctness depends on a user doing extra work to keep it accurate, the model is wrong. Derive state from the actions people already take.

If you're at the same fork

Don't ask whether the idea was bad. Ask what the user was doing instead of using it. That's the product.