This episode features Yako Majuri, a solo founder building Railcode — a platform that gives developers a secure, governed environment to build and deploy internal apps and agents directly from their existing AI coding workflows (like Claude Code), without waiting on DevOps or leaving their tools.
What Railcode is and the problem it solves
Railcode is a platform for building internal apps and agents in a secure environment that lets developers stay in their preferred AI coding harness (Claude Code, Codex, etc.) while providing governance, connectors, authentication, and instant deployment.
The core insight: developers already have workflows, skills, and testing setups in tools like Claude Code; Railcode doesn’t replace that harness — it provides a secure place to put the software they build so it can be shared, governed, and run in production internally.
Historically, internal tooling lived in walled gardens like Retool; Railcode takes the “difficult route” of letting code live on GitHub, run CI/CD, and deploy through Railcode without lock-in.
The one-question test for whether a company needs Railcode: “Are you unable to keep up with your team’s development with AI today?” — i.e., are you holding your team back?
How companies hold teams back without realizing it
Developers at AI-forward companies get access to Claude Code or Codex but then wait a week or more for DevOps approval to deploy something internally — checking authentication, database access, API keys, security standards.
The friction discourages sharing: people give up and run tools locally (single-player), or never build them at all because they don’t know a path to production exists.
The unseen cost is not just the week of delay but the tools that never get built — the “potential gains you can have when people see what everyone else is doing.”
Railcode removes the queue: the CTO audits the environment once (connectors, permissions, security), then the CEO or any employee can build and deploy in seconds without further gatekeeping.
Internal tooling as the product: the Doublepoint → Oura story
At Doublepoint (acquired by Oura), there was no customer-facing product — the company sold gesture-detection algorithms to device manufacturers, so internal tooling was the product.
Yako built the internal data platform and tooling infrastructure; once the environment existed, output exploded: faster model training, more data collection, better models, leadership visibility.
This experience shaped the conviction that most software going forward will be internal, and that giving people a place to build it changes organizational velocity exponentially.
The Solo Founders Program: cohort 5 applications open
The episode is part of a series highlighting founders from the Solo Founders Program (SFP), which runs 3-month cohorts in San Francisco with a $100k investment per company.
Cohort 5 applications are open; about a dozen founders will be selected; kickoff is September 10.
Alumni results: one secured a major US government partnership 5 months post-incorporation; another hit 20k GitHub stars and 3M downloads; a third reached $2M ARR before a single hire.
Demand has grown from 1,000 applications for 6 spots (cohort 1) to 4,500 for 10 spots (cohort 4).
Yako’s path: PostHog, Doublepoint, and pulling the thread
Engineer by trade, backend/infrastructure focus; early employee at PostHog (owned infrastructure, built internal tooling, part of the hackathon team that built v0 of Session Replay).
Joined Finnish startup Doublepoint, owned infrastructure and built the internal platform; company acquired by Oura.
When entering SFP, Yako had pivoted off another idea and was “soul-searching” — reviewed notes from past customer conversations and correlated them with his own experience.
The Railcode idea appeared repeatedly in those notes; it connected directly to problems he’d solved at PostHog and Doublepoint (secure infrastructure that disappears into the background).
Previous product was also security-infrastructure-minded; some code was reused in Railcode — an evolution, not a pivot.
Inside early PostHog: culture as a recruiting and operating system
Yako joined PostHog at ~5 months because of its public handbook — which described how the company would operate, not just how it did.
Three-day work trials confirmed the culture matched the handbook: real values, high autonomy, small teams (≤6 people), freedom to move and start initiatives.
Most core products (including Session Replay) originated from hackathons.
Key cultural pillars: autonomy (hire great, aligned people and get out of their way) and transparency (handbook as living document).
Yako applies this now as a solo founder: fast iteration, active customer learning, engineering culture aligned with PostHog’s.
”Is Railcode fun?” — fun as product strategy
Yako’s website has a playful, roller-coaster aesthetic because “it’s fun for me to build Railcode, and fun is useful.”
Asked a customer: “Is Railcode fun?” Answer: “Yeah, because building things is fun and you’re letting me build fast without the stuff I hate (permissions, security, infra) and without pulling me out of my workflow.”
Fun signals alignment: if the founder enjoys building and using the product, they’ll work harder, stay longer, and serve customers better.
PostHog exemplifies this externally — its brand radiates fun, which reflects internal culture.
Live demo: dark mode deployed in five seconds from Claude Code
Demo shows a demo org in Railcode with a “Combine” app (light mode only).
Yako opens Claude Code locally, types “add dark mode support,” then runs railcode deploy.
~5 seconds later, the deployed app has dark mode — no context switch, no separate dashboard, no DevOps ticket.
The developer stays in their harness (Claude Code, with their skills, browser testing, test setup); Railcode handles governance, connectors, auth, and deployment behind the scenes.
Agents, connectors, and multiplayer by default
Railcode treats apps and agents as first-class peers: apps are immediately accessible to agents without extra wiring — building toward “agents that have UIs” rather than “UIs that have agents.”
Built-in magic SDK provides primitives (database, file storage, LLM APIs) so a CRM can be built by saying “I need a CRM with file storage and customer data” — no infra setup.
Connectors (Granola, Postgres, Google Calendar, etc.) are governed centrally with granular permissions: “Julian can access this Postgres table; Yako can access that one.”
Multiplayer by default: unlike ad-hoc internal tools that use shared passwords and run single-player, Railcode knows who the user is, enforces auth, and makes sharing native.
Serves both non-technical builders (chat-driven) and engineers (code on GitHub, version-controlled).
Advice for solo founders
“Get in touch with yourself and the things you want to build.”
Building something that’s an extension of you means you’ll work harder, persist longer, enjoy it more, and serve customers better.
Yako’s experience: early in the journey, working on something exciting that pulls from his history made everything easier.
