Personal software needs a trusted foundation.

A personal agent should not stop at advice. It should be able to create software around the life, team, and work you actually live.

A checklist for your week. A dashboard for your team. A workflow your company can use. An application you may eventually publish to the world. These should not each become a separate software project.

I've spent 16 years building software, from eye-tracking experiments at Max Planck to ML infrastructure serving hundreds of data scientists at enterprise scale. Now I run the Claude Code meetup in Cologne and watch agents get better every month. But I keep seeing the same pattern: agents can write code, while the path to durable software still depends on humans making the same foundation decisions again and again.

Which framework? Where does it run? Who can access it? Which domain? Which deploy target? How does the agent inspect what exists next month? If those answers are improvised every time, personal software turns into throwaway code.

"What if your personal agent had a trusted place to create, run, and improve software?"

The omakase philosophy

In Japanese cuisine, omakase means "I'll leave it up to you." You sit down, and the chef serves what's best. No menu. No decisions. Just trust.

Ruby on Rails embraced this philosophy: instead of choosing between dozens of tools, you get a curated stack that works. Convention over configuration. The same predictability that makes Rails productive for developers also makes it ideal for AI coding agents like Claude Code and Cursor.

Omaship takes this further. We do not just give an agent Rails. We give it Omaship Skills and the creation and deployment layer: app foundation, domains, access, deploy targets, health checks, security scanning, and context it can read when it comes back later.

The skills matter because most useful software is not invented from zero. Approval flows, personal dashboards, directories, internal tools, onboarding checklists, lifecycle pages, and public applications all have patterns. Omaship Skills package those patterns so Sokrates can start from a proven way to build, not just a blank codebase.

For the parts that are even more fixed, Omaship can use engines: the static SaaS building blocks that have been created hundreds of times before. The point is not to make you think about engines. The point is that the skill can reach for the right foundation piece and keep moving.

The name? Oma from omakase. Ship because software should move from idea to running URL.

Built for Sokrates first

Sokrates is the agent people will feel: the assistant that helps decide what should exist. Omaship is the creation layer underneath that gives Sokrates skills, CLI, Rails, and deployment for software people can trust.

If someone wants to use Omaship directly, great. But the first job is simpler and more important: make sure Sokrates can build software for real people without leaving them with fragile prototypes, mystery infrastructure, or code nobody can own.

We run our own products on Omaship:

• Cozama - Priority management for startup founders
• Chaodinator - AI-powered daily task prioritization
• MySokrates - The personal agent service Omaship is being built to serve

Every feature in Omaship exists because we need Sokrates to rely on it. Every skill is a piece of web app judgment we want an agent to reuse. Every default is something we'd choose for ourselves. Every architectural decision is one less thing standing between a person, their agent, and software that fits their context.

Start personal. Share with your team. Launch when it should exist.

— Jeronim