One person.
Any device.
An AI.

20 years watching the problem.
Then he stopped watching.

Suman Akkisetty grew up in a small town in India. Computers were just another subject on the timetable. But something happened in Grade 12 when he first saw a machine respond to code he had typed. He couldn't explain it. He just knew he wanted more of that feeling.

He taught himself everything, entered the IT industry on passion alone, and spent the next two decades working at some of the biggest technology firms in the world.

The whole time, there was an idea in the back of his head. Not vague, not merely a "someday" thought, but a specific problem he kept encountering everywhere he worked. He tried to build something around it a few times over the years. Nothing stuck. Life got in the way. But the idea never went away.

With two decades of experience and AI finally capable enough to make it possible, he decided to actually do it. No investment, no team, no one to direct, no one to guide. Just a personal laptop, a phone, a cloud server with 1 GB of RAM, 45 GB of storage, and a 2-core CPU, and the stubborn refusal to let the idea die again.

The problem with how enterprise software gets built

Enterprise software has a reputation for being expensive, slow, and built by large teams behind closed doors. It takes years, millions in funding, and sprawling infrastructure just to ship something that a medium-sized company might actually use.

Suman had worked inside enough organisations to understand the problem from the other side - teams paying for five, six, seven separate SaaS subscriptions to get things done. Outlook for email. Slack for chat. Jira for tasks. Confluence for docs. Notion for notes. ServiceNow for incidents. All of them siloed. None of them talking to each other. None of them yours.

The question wasn't whether a better platform could exist. It was whether one person could actually build it.

The radical setup

Most software is built at a desk. Fixed hours, fixed location, fixed machine. Suman's approach was different - not because he abandoned the laptop, but because he refused to be chained to it.

The laptop was always there when needed. But the phone was equally present: on the couch, mid-walk, during commutes, right before sleep. Wherever a window of time opened up, features got shipped. Claude, Anthropic's AI, handled the heavy lifting as a co-developer, making it possible to move quickly without a full development environment in front of him. MongoDB, Go, a basic Oracle Cloud server. The whole stack was chosen to be lean, self-hosted, and easy to iterate on from anywhere.

Features were shipped from wherever life happened to be, not just from a desk.

On a personal trip to Toronto, Suman shipped SSL certificates for a new domain, wrote the full product documentation, and built the automated install wizard, all from a mobile browser, with no laptop in his bag. That is not a workaround. That is the workflow.

The desk was optional. That was always the point.

What made it possible

Not a story about grinding. A story about the right tools. Each piece of the stack was chosen to multiply what one person could do.

18x faster. Overnight.

The first four months were slow. Local machine, standard setup, 53 commits from November through February. Real progress, but grinding.

Then, in March 2026, a thought crossed his mind that seemed almost too simple to take seriously. What if the entire development environment (the compiler, the AI, the server, the logs, all of it) lived in the cloud, and the only thing he needed locally was a browser tab? He had never heard anyone describe building production software this way. It was not in any tutorial. It just seemed like it might work. That instinct turned out to be the most important technical decision of the entire project.

The security had to be tight. Triple-gated admin access, encrypted credentials, rate limiting, org-level data isolation on every query. The kind of setup that normally requires a security team. Built by one person, verified by one AI, running on hardware most developers would never take seriously.

There was one more constraint that never made it into the commit log. Every AI session has a token limit, and he was hitting it constantly. He learned to front-load the important decisions, compress context without losing it, and work smarter inside those limits. The clock was always running. That pressure is in every commit from March onwards.

The numbers show what happened next:

438 in March. 428 in April. 601 in May. 237 and counting in June. The work didn't get easier. The clock just got louder.

Not autocomplete. A real collaborator.

People hear "built with AI" and picture someone typing prompts and copying answers. That is not what happened here. The AI held full context of the entire codebase across every session: decisions made three weeks prior, architectural trade-offs, security gaps, inconsistencies that needed resolving. It flagged problems before they reached production and pushed back when something was wrong.

Suman's job became deciding what to build and in what order. That's a genuinely different way of working than anything that existed a few years ago.

What got built

Not a prototype. Not a demo. A production platform, shipped iteratively over months of snatched moments.

This was built at night.

Suman held a full-time job throughout the entire build. Every commit was pushed in the evenings, through the night, and across weekends. The working day belonged to someone else. There was no sabbatical, no runway, no "building full-time." Just the hours that were left over, used completely.

From 17 March to 20 April 2026: 35 consecutive days without a single gap. From March onwards, not one weekend was skipped. Every Saturday and Sunday through to launch saw code shipped. A full-time job during the day. A platform being built at night. No grand plan, just what happens when the problem matters enough.

What 6 months actually looks like.

A full production enterprise platform, built by one person on free cloud infrastructure, shipped from wherever he happened to be. Not a demo. Not an MVP in the loose sense of the word. Production-grade and fully deployed.

A platform. Not an app.

Most software you pay for doesn't belong to you. It lives on someone else's servers, priced by their terms, shut down on their schedule. WorkSpace is different in a structural way: it runs on your server, under your domain. The mail server is yours. The AI queries your data. The CRM belongs to your organisation. No vendor access. No dependency on anyone staying in business.

That is what platform means. Not a larger feature set. Not a higher pricing tier. Ownership of the infrastructure your organisation runs on, with no vendor who can revoke it.

Two ways to use WorkSpace

WorkSpace is built to meet organisations where they are. You don't have to rip and replace your existing tools to get value. Two distinct operating modes let you choose how deeply you want to adopt the platform.

Both modes share the same AI layer. Whether you are bridging existing tools or running everything natively, the AI has full context across your organisation's data and can answer across all of it.

Why KaryoSpace

The name wasn't chosen for branding. It was chosen because it meant something, in two completely separate ways, from two ancient languages, both pointing at the same idea.

The product name, WorkSpace, is literally the English translation of KaryoSpace. That's not a coincidence. It's the point. The domain, the product, and the idea are the same word in three languages, all saying the same thing: the nucleus of your work, the place where purposeful action happens, yours to own.

Self-hosted was always part of the name's meaning. A nucleus you don't control isn't a nucleus. It's a dependency. KaryoSpace exists so that the centre of your organisation's work belongs to your organisation.