Aji Abraham's case for keeping the day job

Aji Abraham has a customer in mind: someone who knows a business well enough to see what software could change, but cannot build the software. Perhaps that person also has a salary worth keeping. The usual advice about entrepreneurship can make this awkward. Find a co-founder. Learn to code. Take the leap. Abraham has spent years making another route available: bring the idea and the industry knowledge, and work with a technical partner.

He has reasons to understand the attraction. Before running his own businesses full time, he spent a decade at Motorola as a software engineer and product manager. Today, his companies cover custom development, server administration, software products and startup partnerships. The distance between a corporate job and a new venture is territory he has crossed himself.

His writing suggests he has little patience for making that crossing sound mystical. A founder needs customers, access to the code and an agreement with the people doing the work. The leap, in this account, comes with paperwork.

Before the pitch deck, a nickname

Abraham grew up around Muvattupuzha in Kerala. His father worked in the police force, which earned the son a school nickname: Police. His recollections are cheerfully informal, full of jokes about education and his attempts at guitar. His musical interests ranged from heavy metal to Indian classical music; he also described an early music website project. The internet was already becoming something to make things with.

He studied engineering at the College of Engineering, Trivandrum, completing his undergraduate course in 1993. Later came an MBA and a master's in information management at Arizona State University. Engineering and business became adjacent subjects in his education, before they became adjacent jobs.

At Motorola, his work included software for wireless providers and roles in product and engineering management. Those jobs put several different questions on the same desk: what the technology can do, what a customer needs and what a team can deliver. They would recur throughout his own businesses.

A company with work on both shores

Armia Systems began in April 2001 with two staff. Its Indian operation began in April 2004. The business grew around a connection between Illinois and Kochi, rather than a single office doing everything.

Architecture and requirements work in Chicago connect with much of the technical development carried out in India. Armia's development center is in Kochi's Infopark. For a founder hiring the company, that arrangement links the conversation about what a product should do to the engineering work needed to make it happen.

The work also branched. SupportPRO handles remote infrastructure management, including server administration and DevOps. At iScripts, the emphasis is on business software products that customers can obtain with source code and adapt. Custom development, operating infrastructure and reusable software sit alongside one another in Abraham's working life.

These are different answers to a practical question. A company may need software designed around its particular operation. Another may be able to begin with an existing product. Both will eventually need someone to keep the system working. Abraham's businesses address several points along that journey.

The day job gets a reprieve

CodeVentures, established in 2016, takes the relationship further into the startup itself. Abraham describes its audience as including mid-career entrepreneurs who want to develop a technology venture without immediately leaving their employment. Their experience may tell them where a market has a problem. It does not automatically provide an engineering department.

The studio offers technical co-founder support, with development costs covered through a combination of cash and equity. That distinction matters. The arrangement involves both payment for work and a stake in what the work becomes. A promising idea still needs a defined product, a budget and people who can execute it.

A discovery workshop is intended to turn the concept into decisions about user flows, the first product, architecture, development timing and how the business will reach customers. These are the subjects that an enthusiastic pitch can leave conveniently blurry. A workshop gives the blur an appointment.

The relationship can continue beyond launch. CodeVentures describes helping partners establish their own technical teams after funding or revenue, with Abraham available as an interim CTO. The offer therefore includes a possible handover: help the company reach the point where it can organize more of its engineering work itself.

The arithmetic gets personal

When Abraham writes about dividing ownership, the voice becomes particularly direct. He describes working with capable founders who understand their industries and customers, yet struggle with the mechanics of starting together. An equity discussion can consume the energy that was supposed to go into the company.

“Please remember 100% of nothing is still nothing.”

Aji Abraham, on splitting co-founder equity

He asks founders to consider money, effort, salary and opportunity cost. Two people can be equally enthusiastic while making quite different contributions or taking different risks. He discusses vesting and a cliff period as ways to address another familiar problem: someone leaves early, while a substantial part of the ownership leaves with them.

There is a useful lack of romance here. Founders can like each other and still need explicit terms. Their circumstances can change. A fair-looking division on the first day may feel different after months of unequal work. Abraham's attention stays on making those expectations discussable.

He brings similar specificity to the product. In an essay about a new app idea, he asks founders to identify their potential users closely. An answer as broad as “anyone” needs more work. He wants them to investigate demand and whether those people will pay. Free products also ask for something: attention and time.

He then turns to the route to those users. Launching software does not arrange its distribution. Cold calls, advertising, partnerships and other channels belong in the thinking before a founder assumes a finished app will attract a crowd. His business sells development; his advice spends considerable time on what development alone cannot accomplish.

A CV learns to talk

In 2021, Abraham's work included a collaboration with Hotmail co-founder Sabeer Bhatia. Their product, ShowReel, used short video profiles to help job seekers introduce themselves and entrepreneurs present ideas. Abraham was co-founder and CTO, steering a core development team of ten engineers.

The design centered on questions. A person would answer prompts of the kind a mentor or hiring company might ask. The responses could then be assembled into a professional video profile. It offered a way to make an introduction through conversation, without requiring the speaker to invent a performance from a blank screen.

Abraham described the aim as allowing job seekers to talk about themselves naturally. There is a recognizable connection to his work with startup founders: people may possess experience worth hearing about while needing help with the form in which it reaches someone else.

By October 2023, ShowReel had moved toward AI-based learning and announced an entrepreneurship programme with Jamia Millia Islamia. The shift broadened its educational work. It also gives the product's history a turn beyond its original video résumé format.

Who has the keys?

Some of Abraham's most revealing observations concern what happens after the first version exists. In a post about moving from remote developers to an in-house team, he describes encountering businesses without access to their own source code or server infrastructure. Sometimes even the domain name sits beyond the customer's control.

The handover advice also exposes an uncomfortable feature of buying software. A business owner can pay for a product and still depend on one person to explain how it works. Abraham describes documentation as something the developers with first-hand knowledge should create. Getting it right is work for the original team, while the incoming team needs time to become familiar with the application. That makes continuity part of the product discussion, rather than a matter to raise only after a relationship has ended.

His response is specific: establish ownership, retain access and document the system. The incoming team should be able to set up a development environment, run tests and deploy changes. A demonstration can look finished while these arrangements remain unsettled. The next developers will discover the difference soon enough.

He also asks founders to decide whether an initial product is meant to become the foundation of the business or serve as a disposable test. Both can have a purpose. Knowing which one is being built changes expectations about what comes next.

His mentoring work extends to students. In January 2022, Armia and Rajagiri School of Engineering and Technology announced cooperation on research and entrepreneurship. Plans included a collaborative workspace, technical participation and mentoring in technology, marketing and finance for student and alumni startup ideas.

He has also spoken at Chicagoland high schools, the Chicago startup hub 1871 and Hostingcon. His subjects include entrepreneurship, software development and infrastructure management. The settings reflect the range of his work, from people considering a first venture to people responsible for operating technology.

The same concern runs through these different settings: how to give an idea enough practical support to become something people can try. Abraham's blog addresses founders who doubt their qualifications, too. He reminds them that they can learn and find people with complementary skills. There is room to begin without already knowing every job.

The encouragement has conditions attached, and that is what makes it interesting. Find the customer. Discuss the equity. Keep the code accessible. Work out who will build the next version. The day job may stay in place for a while. There is already plenty to do.