An invitation to a rare kind of work

There are projects, and then there is the project that has no stack to stand on.

Five short pages · about 20 minutes

Most engineering careers are spent building on something — an inherited platform, a framework, a set of decisions made by someone else, years ago, that quietly bound the design before the first line was written.

This is not that. This is the rarer case: a project where the technology stack itself is being created — the data model, the identity model, how things are stored, how they talk to each other, the language, the runtime. Where design genuinely precedes architecture, because there is no architecture yet for it to defer to. The freedom is total. So is the responsibility. Every load-bearing decision has to be derived from first principles, because nothing can be borrowed.

Tally calls this a full-stack greenfield project. The industry usually uses "greenfield" loosely — for a new product built on a borrowed stack. That is a different and much smaller thing. This is the literal version: nothing underneath that was decided for you.

It is the only class of project in which design is the make-or-break discipline — because there is nothing to lean against.

We are writing to a small number of people who might want to do that kind of work. Not to sell you on it — the work sells itself to the right person and is genuinely wrong for everyone else. To tell you enough to know which one you are.

Who this is forThree kinds of senior people

We are looking for three kinds of senior people. We will not give them industry job titles, because the titles would mislead — what these people do here does not map cleanly onto what those words mean elsewhere. Described by the work itself:

People who design the thing before it exists — who can hold a problem at the level of structure, decide what must be true at the foundation, and specify it completely enough that it can be built without quietly inventing the missing decisions in code.
People who turn a design into a buildable architecture — who own the contract between what was designed and what gets constructed, and who can keep a single, coherent codebase honest across four operating-system families at once.
People who build at the standard this requires — senior engineers for whom "it works" is the beginning of the job, not the end; who can deliver code that is provably correct, not merely tested-and-shipped.

If none of those is you, this will read as overwrought. If one of them is you, the next four pages are the most honest account we can give of what you would be walking into — the problem, why it is genuinely hard, what building it actually demands, and why a particular kind of person finds that irresistible rather than alarming.

A note on what we will and won't say We will be specific about the problem and honest about the weight. We will be deliberately spare about the answers. Not to be coy — the answers are the result of years of work, and they are also the kind of thing that is easy to misread from the outside. You will see them properly when you are inside. What we can show you here is whether the problem is worth your attention.

02 — The problem worth a career

A country does not do business one way. Software almost always pretends it does.

India is not a market. It is tens of millions of businesses, each of which has, over decades, evolved a way of operating that works for it — and almost none of which match.

The textile trader in Surat books a sale differently from the pharma distributor in Hyderabad, who books it differently from the kirana store on the corner, the steel re-roller, the export house, the temple trust. Not by a little. By kind. What counts as a unit, a price, a credit, a return, a "done" — all of it varies, and all of it is correct for the business that does it that way.

The standard answer is to pick the average business, build for it, and ask everyone else to bend. Configuration toggles at the edges. Consultants to fill the gap. A long tail of customers the software was never really for. It is how most enterprise software is made, and it is why most enterprise software is quietly resented by the people who have to use it all day.

Most software asks the business to change shape. The problem worth a career is software that takes the shape of the business.

The problem we are interested in is the inverse. Build a system that does not assume a shape — that lets each business describe its own, in its own terms, and then runs that description faithfully. Not a thousand forks maintained by a thousand teams. One system, general enough that the textile trader and the temple trust are both first-class citizens, and neither one was anticipated by name when it was designed.

Generality is easy to say and brutal to deliver. A system general enough to be anything is usually too vague to be useful and too slow to be trusted with money. The narrow path — general and exact and fast and comprehensible to the person actually using it — is the entire problem. It is also the only version worth building, because the businesses on the long tail are not a rounding error here. In aggregate, they are the country.

Why this, why nowThe raw material already exists

Tally has spent decades learning the true shape of these businesses the slow way — by being used, every day, by millions of them. That accumulated understanding of how Indian business actually works is the raw material, and it is not something a new entrant can buy or shortcut. What is being built now is the system that can finally hold all of it without flattening it: a new data model, a new way of describing a business, a runtime fast and certain enough to run the result at scale.

Why we can be exact about the problem We can describe the problem precisely because we have lived inside it for nearly forty years. We will be deliberately spare about the solution, because the solution is the work itself — and because a half-described answer is worse than no answer at all; it invites you to judge a sketch instead of the thing. The problem, stated honestly, is enough to tell you whether you want in.

03 — Why it's genuinely hard

The hard part is not building it once. It is keeping it true everywhere, forever.

Plenty of systems are hard to build. This one is hard to keep correct — across platforms, across edge cases, across decades — which is a different and more demanding thing.

It is worth being concrete about the constraints, because they are what make this a problem you could give a career to rather than a quarter. None of them is exotic on its own. The difficulty is that they are all true at the same time, and none of them can be set down.

Generality without vagueness. The system has to be open enough to take the shape of any business, yet exact enough that a number means precisely one thing. Most general systems buy their flexibility with ambiguity. Here, ambiguity is failure — this is the ledger a business runs on.
Correctness as a precondition, not a goal. A wrong number is not a bug to triage next sprint. It is a figure someone files with the government, shows a lender, or pays tax on. "Mostly right" is a category error. The system has to be right by construction, in ways that can be demonstrated — not merely right in the cases someone remembered to test.
One codebase, four operating-system families. Windows, macOS, Linux and mobile are not four ports of a product. They are one product that must behave identically on all of them, from a single coherent source. The moment they diverge, "Tally" stops meaning one thing — and holding that line indefinitely is a structural pressure, not a one-time effort.
Speed that feels like nothing. The general system has to be as fast as the hand-tuned, special-purpose one it replaces — fast enough that a user posting their ten-thousandth voucher of the day never once thinks about it. Generality almost always costs speed. Here it cannot be allowed to.
Decades, not quarters. What is decided now is decided for a very long time, for millions of businesses, and much of it cannot be changed later without breaking the trust the product is built on. The cost of a shortcut is not paid by the person who takes it.

It is the only class of project in which "it works on my machine" is not even the beginning of the conversation.

The reason it's a career, not a quarterThe constraints compound

Each of these is hard alone. What makes the problem worth a career is that they multiply. General and exact. Exact and fast. Fast and identical across four platforms. Identical and stable for decades. There is no constraint you can quietly relax to make room for the others — relax any one and the thing stops being the thing it has to be. The design has to satisfy all of them at once, from the foundation, or it does not hold at all.

An honest checkpoint This is the page where most people quietly decide it is not for them — and they are right to. The constraints do not loosen later; this is as gentle as they get. If reading them makes the work sound heavier than it's worth, that is the honest signal, and you should trust it. If reading them makes the work sound interesting — if you found yourself arguing with how to satisfy two of them at once — keep going.

04 — What building it takes

What building this actually demands, stated plainly.

Not values painted on a wall. The specific habits of mind the work requires of the people who do it — and the trade you would actually be making.

Because there is no stack underneath, the usual skills rearrange. Knowing the most frameworks helps less than you'd expect. What the work rewards is narrower and harder, and it shows up in four places.

Derive, don't borrow. Every foundational decision has to be reasoned from the problem, not copied from a framework that solved a different one. The skill that matters is being able to sit with a blank foundation and derive the right structure — and to tell the difference between a decision that is genuinely forced by the problem and one you are making out of habit.
Specify completely. A design that is ninety percent specified is a design that gets finished in code by whoever happens to be typing, under deadline, badly. The work demands specifications complete enough to build from without inventing the missing tenth — and the discipline to go find that missing tenth before someone else finds it the hard way, in production.
Own the seam between design and build. Someone has to hold the contract between what was designed and what gets constructed, and keep it honest across all four platforms, in one codebase, as it grows. This is not project management. It is architectural authorship — keeping a large system coherent while many hands build it at once.
Treat "it works" as the start. For the senior engineers here, a feature that passes its tests has barely begun. The standard is code that is provably correct — reasoned about, constrained so the wrong state cannot be represented, demonstrated rather than hoped for. Tested-and-shipped is table stakes. It is not the bar.

The work asks for people who are made uneasy by "good enough," and quietly relieved by "provably right."

The trade you'd be makingTotal freedom, zero excuses

In return for total freedom you give up every excuse. No legacy to blame. No framework that "made us do it." No prior team's decisions to inherit and resent. When something at the foundation is wrong, it is wrong because of a decision someone here made, on purpose — and it can be traced to them. Some people find that terrifying. The people this is for find it clarifying: it is the only condition under which the quality of your thinking is the only thing that determines the quality of the result.

On titles We are describing a small number of senior roles, and we are deliberately not attaching industry titles to them — the titles would tell you the wrong thing about the work. What matters is whether the four habits above read as a burden to endure, or as the job you have been waiting for someone to finally offer you.

05 — Why you

Why a particular kind of person finds this irresistible rather than alarming.

Everything in these five pages has been an attempt to let you self-select — honestly, in private, before any conversation with us.

If the constraints read as a list of reasons to say no, that is the correct reading, and you should say it. The work is genuinely wrong for most very good engineers. There is no shame in that — "wrong for you" is not "beneath you." It is simply a different appetite, and pretending otherwise would waste your time and ours.

But a small number of people read "no stack to stand on" and feel something closer to relief. They have spent careers being handed foundations they could see were wrong and were never allowed to fix. They have made an uneasy peace with "that's just how it is here." To them, the idea of a foundation with no inherited mistakes — where the only constraints are the real ones — is not frightening. It is the thing they have been quietly hoping someone would finally ask them to build.

We are not trying to convince you. We are trying to be found by the few people who were already looking for exactly this.

If that is you, you will not need to be persuaded. You have been arguing with yourself about a problem like this one for years. We are simply telling you that it exists, that it is real, and that it is being staffed deliberately and kept small.

What happens nextThere is no form with twenty fields

If the problem has stayed with you — if you have been turning it over since the first page rather than skimming to the end — write to us, in your own words, about a foundation you once had to build, or one you wished you could have rebuilt. Tell us what you would have decided differently, and why. That is the entire application.

One request: be specific about the problem, and spare about your credentials. We will infer the credentials from how you think about the problem — which is, after all, the whole basis on which the work itself is judged.

Please write to us at stella.thomas@tallysolutions.com

A note on confidence We have been deliberately spare about the answers throughout. That was not evasion — it was respect, both for the years of work the answers represent and for your ability to judge a problem on its own terms. If the problem was enough, you already know. We look forward to hearing how you'd build it.