Create from proven patterns
Turn 'we need a supplier approval flow' into Rails software guided by a skill, not a blank prompt.
For Sokrates, agents, and builders
Give Sokrates a creation layer you can trust.
Create personal software, team workflows, and public applications on Rails without treating every request like a new product build. Human decides. Sokrates orchestrates. Omaship creates and deploys.
Feedback returns to the context, so the next change starts from what already exists.
-
01
Decide
A human chooses what should exist.
-
02
Orchestrate
Sokrates turns intent and context into a useful plan.
-
03
Create
Omaship gives the agent Rails, skills, CLI, and deployment.
-
04
Improve
Feedback returns to the context for the next change.
Why Omaship exists
Agents can generate code. That is not scarce anymore. What is scarce is a repeatable path from request to running software that people can trust.
Omaship packages the web app judgment we built over ten years: skills for high-impact app types, Rails structure, focused scopes, deployment, security checks, and context files agents can read later.
It does not invent the business. It gives Sokrates and other agents the creation surface, CLI, and Omaship Skills to build the app, page, or workflow you asked for.
Sokrates
- Understands the request and constraints
- Chooses the useful software shape
- Plans copy, data, flows, and next changes
- Keeps the human in the decision loop
Omaship
- Provides the app creation API and CLI
- Chooses Omaship Skills for common app jobs
- Generates the Rails surface agents can edit
- Deploys personal, team, or public applications
- Leaves code humans can inspect and own
Principle: Sokrates is the umbrella agent service. Omaship is the creation layer underneath it. Sokrates decides what should exist; Omaship creates the Rails-backed software surface and keeps it deployable. Inspired by the Rails Omakase philosophy.
How the pieces fit together
Sokrates is the personal agent people interact with. Omaship is the layer underneath that gives it skills, creation, deployment, and infrastructure.
Skills guide the agent through proven app patterns. Engines provide solved building blocks when the problem is static. Harbors run the resulting software for private, team, or public use.
Omaship Skills are the multiplier.
Not just an AGENTS.md file. Omaship gives agents reusable playbooks for creating focused software that has been built many times before.
Build for one team or company
Create software around a real company context without forcing it into a generic SaaS shape.
Use engines for solved parts
When auth, billing, teams, or other static building blocks are clear, skills can use Omaship engines instead of rebuilding them.
Publish only when it should be public
Keep work personal, make it useful for a team, or publish an application to the world.
Work through API and CLI
Give agents commands for creating, inspecting, and deploying instead of making humans drive setup screens.
Come back later
Agents can inspect context, pick the next skill, change a flow, publish a page, or remove what is no longer needed.
The foundation is the multiplier
Rails, CI, and Kamal are ordinary on their own. They become useful when an agent can reach for the same proven foundation every time it creates software.
01
Built for focused jobs
The output starts as software for one clear job, not a platform waiting for imaginary future requirements.
02
Skills survive the prompt
Omaship Skills carry repeatable product and implementation judgment, so Sokrates is not rebuilding each app type from scratch.
03
Context survives the prompt
AGENTS.md and Rails conventions give Sokrates enough structure to inspect what exists and decide what should change next.
04
Engines handle stable building blocks
For the parts every SaaS starter repeats, Omaship can use engines behind the scenes while skills keep the agent focused on the job.
05
Humans can review it
Models, controllers, views, routes, and jobs live where Rails developers expect them. You can audit the result instead of trusting a black box.
06
Deployment is part of creation
Kamal, health checks, and CI give the generated thing a path from local change to running URL without a separate ops project.
07
Simple enough to create often
SQLite, Solid Cache, Solid Queue, and Solid Cable keep the default stack understandable until the app earns more complexity.
08
Defaults from real web app work
Omaship carries our experience from shipping web apps: security checks, clean boundaries, restrained dependencies, and enough tests to change things later.
Why we built it this way
Why SQLite over PostgreSQL?
SQLite is massively underrated. With Rails 8 optimizations and SSD storage, you can make thousands of SQLite queries in the time it takes for one PostgreSQL network roundtrip.
Zero configuration, incredible performance, simple backups. When you outgrow it, migration to PostgreSQL is straightforward.
Why Kamal over Heroku/Fly/Render?
PaaS is convenient but expensive and limiting. Kamal gives you Heroku-like deployment to any server. Hetzner, DigitalOcean, your own hardware.
Result: 10x cost savings, full control, no vendor lock-in.
Why Hotwire over React/Vue?
Most SaaS apps don't need heavy JavaScript. Hotwire delivers SPA-like experiences with server-rendered HTML. Faster development, better performance, simpler architecture.
Need React? Add it to specific pages. Best of both worlds.
Why Rails is ideal for AI coding tools
Convention over configuration means predictable structure. Claude Code and Cursor don't guess where things are—they know.
Two decades of established patterns = rich training data. Every Rails app follows the same structure. Models in app/models, controllers in app/controllers, views where you'd expect them.
Unlike Next.js projects where folder structure is a choose-your-own-adventure, Rails apps are consistent. AI tools thrive on that predictability.
Give Sokrates a creation layer you can trust.
Use Omaship as the skills, CLI, Rails foundation, and deployment layer underneath the agent that decides what should exist.
Get Omaship