How It Was Built
Minix. Two modems. Pin-based hard drives. A year of work. No funding. It worked.
The Hardware Problem
The goal was clear: a system that could operate on UUNET, exchange information between users across institutions, and maintain a shared data store with user accounts.
The mainframe in the closet couldn’t do it — it had no external network access. So Dokken visited a computer firm in his city. They had a new category of machine: a CPU that was not a mainframe. A micro-processor system from IBM.
He purchased one. It was a jail.
Nothing customizable. Simple DOS commands. A closed box with no capacity to extend beyond what IBM had shipped. Useless for the purpose.
The Second Machine
A new version came out. This one had a bus — an architecture that could support multiple processes simultaneously. Dokken exchanged his system for the new version.
It was still a block. But it was a block with a door.
Investigation followed. The question was: what operating system would run on this IBM micro-processor and allow the kind of deep customization the project needed?
Minix
The answer was Minix — an operating system being used to teach new OS and database models. It was among the first open-source systems of its kind that would run on the IBM micro-processor architecture and allow real customization.
This was the foundation. With Minix, the build could begin in earnest.
What Was Built
The system was customized to run two modems simultaneously — something that did not exist as a product and had to be built from the ground up.
It synchronized with a single shared database. Users could log in once and access multiple accounts — a text-based user and account store that was, in effect, the first version of what the industry would later call single sign-on. Data pulled in from the network for shared access. Multiple users. One data store.
The original SuccessInc architecture — drawn at the time it was built, not reconstructed later
The Work
It took almost a year.
The hard drives of the time operated on pins. Not platters spinning at speed — physical pins. Each read and write was mechanical. Slow. Precise. Making a database respond in anything approaching real time across a modem connection was a long and demanding process.
The development team worked through the technical constraints one by one. Got two modems running simultaneously against a single data store. Built the account structure. Pulled in data for shared access.
There was no financial support for any of this. Dokken worked during the day to pay for the hardware and the systems. The development happened around that.
The Application Gateway architecture — server, repository, data store, dual network — as designed
The Accusations
Before the system was fully deployed, Dokken was accused of being about to destroy the insurance industry.
Not the community platform. Not the data infrastructure. The insurance industry specifically — even though the first application being developed was for employment recruitment. Insurance had been discussed as a future direction. That was enough.
The accusation was that a platform which delivered applications over a network would eliminate the need for brokers, agents, and the entire distribution layer the insurance industry depended on. They were not wrong about the direction. They were wrong about who was being accused, and wrong about the timeline.
It Worked
UUNET became a paid service. The window for free institutional networking closed.
But by then, the system was running. Two modems. One database. Users logging in. Data shared. An application delivered as a service over a network — before that concept had a name, and before anyone who had heard about it believed it.
That was the reward. Not money. Not recognition. The reward was that it worked.
The Architecture — As It Was Drawn
These diagrams were created at the time. They are the record.
AppNet setup — repository, application, theme, users, accounts, data store, BBS network
User login, accounts, data store, network access — the full AppNet access model