fryga, we ship on Fridays Kraków / Oslo / remote Currently booking: Q3 2026

Hard product
problems on Rails.

When shipping stops. When scaling breaks. When AI isn't sticking.

We are a team of four product engineers. We work with product companies beyond the MVP stage — in sprints, usually two weeks. You keep everything we build, and you can stop after any one sprint.

See the work → Book a call →

01 Problems

One team. Three problems we recognize.

01 / Rescue

"We can't ship."

Your delivery has stalled. The codebase fights every change. The team that built it isn't here anymore.

→ Domestika

02 / Scale

"We need to scale this."

You've shipped a working product in one place. The next four places want it too, and each has its own constraints.

→ FastTravel

03 / Ship with AI

"AI isn't sticking."

Pilots ran. Demos happened. Delivery looks the same.

→ nerds.family + Gyfted

02 Case studies

Three problems. Four engagements.

— 01 · Rescue · Domestika ↗︎ · unicorn · 11 months

The codebase had four architectures pretending to be one app.

Domestika serves millions of creative professionals. Thirteen years of Rails, mid-restructure. The codebase mixed react-on-rails, regular Rails, separate React apps, and internal libraries that reinvented the wheel. Delivery had stalled.

The CTO called us to decide what stays and what dies, not to write more code on top of the mess. We killed react-on-rails entirely, converted views to Stimulus, and rebuilt the abandoned Community module from scratch. Then we shipped a contest platform on the new foundation and replaced the tests that weren't catching real bugs with ones that do.

RailsStimulusTypeScript

−40% deploy time

The team that inherited the codebase could actually read it.

Marcin Ostrowski · Katarzyna Kukułka · Wojciech Janoszek

— 02 · Scale · FastTravel ↗︎ · 3 years, ongoing

One airport worked. Then the next four needed it too.

We've been part of FastTravel since day zero, through the launch at Oslo Airport and the scale that followed. Before designing a single screen, Katarzyna went to the queue and watched: passengers fumbling, drivers idle four hours for a single fare, support staff drowning. The first version came from what she saw.

Oslo worked. Then Bergen, Trondheim, Stavanger, and Tromsø wanted it. Each site had its own layout, payment rules, and operational reality. Going from one airport to five forced multi-tenant architecture, per-region configuration, and a payment system that handles invoicing, billing, corrections, and automatic passage fees at every airport. Without forking the codebase.

RailsHotwire NativePayments

4h → 30min driver wait

The five biggest airports in Norway on one multi-tenant system. One of us still runs the payments, three years in.

Marcin Ostrowski · Katarzyna Kukułka · Mateusz Baltyn

— 03 · Ship with AI · nerds.family ↗︎ + Gyfted ↗︎ · nerds.family completed · Gyfted ongoing

AI finally stuck when the people closest to the customer could ship it themselves.

nerds.family has run coding academies for four years. The platform needed to grow to three academy types — no dev team, no budget to hire one. Marcin worked through what the market offered and built the harness from what held up: conventions encoded in the repo, review enforced, rollback automatic. Open source, in production since December 2025.

A CPO with zero engineering background wrote product specs against a codebase the AI knew; agents wrote the code; Marcin made the calls. Two people, part-time, shipped to production daily for seven months.

The harness isn't married to Rails. Gyfted builds psychometric assessments on a stack we don't usually touch. Same harness, same guardrails, and they held. Their CPO now ships landing pages to production on his own schedule, no developer in the loop.

If you already have an engineering team, the harness works with it, not around it: your conventions in the repo, your engineers on the review gate.

RailsAI harness

7+ mo AI in prod, daily

We handed the system off in June 2026 and left. A month later, the daily releases haven't stopped.

Marcin Ostrowski · Katarzyna Kukułka

"They would not only provide their services, but also take the product as their own. Questioned what needed to be questioned, and eventually saved us from making some silly mistakes."

Oskar Lakner · CEO @ nerds.family

Sound like where you are? Book a 30-min call →

03 How we work

"How much time do you want to spend on it?"

That's our opening question. The usual one — "how long will it take?" — has no honest answer, only a guess. So we flipped it: you decide how much time the problem is worth, and we tell you what ships inside it, usually two weeks at a time. We start with the decision sprint. We talk to your team, read the codebase, and map the mess; then, before we write a line, we tell you what we'd kill, what we'd keep, and what we'd build first. We spend the rest of the week building the first of them, in your repo.

— 01

One call.

You tell us what's broken. We ask questions until we understand what's actually going on. If we're not the right fit, we'll say so.

— 02

A sprint plan.

You set the time, we fill it: what ships in that time, and the price, agreed before we start. If something has to give, it's scope, never the date.

— 03

The work.

Direct access to whoever's doing it, no standups to schedule. At the end of the sprint, something ships.

— 04

Your call.

Continue, pivot, or stop. The work earns the next sprint, not a contract.

The engagements still run long — Domestika was eleven months, FastTravel is three years and counting. Just one sprint at a time.

We're a Kraków team with Norwegian co-owners at Rubynor; we've shipped in both markets and can open doors in either.

When something breaks at 3pm on a Friday, we fix it Friday, not Monday.

We pick up the phone and answer on Slack. No handoffs, no "let me check with the team," no vanishing into a process.

Start with the one call. Book it →

04 Team

The four people making the calls.

No bench. These are the people who'll be in your codebase. Who you get depends on the problem, and you'll know their names before the sprint starts.

Marcin Ostrowski

Founder / CEO

LinkedIn ↗︎

Kept hiring the same people at every company he built, then stopped pretending that was a coincidence and made it a company. fryga is the band he always wanted: small, handpicked, no bench. Too many ideas on a normal day, the anchor when something's on fire. Answers for the result, not the task list. Writes about Rails and AI-assisted coding at rubyonai.com. Mentors at 42 Warsaw.

Katarzyna Kukułka

Product engineer

LinkedIn ↗︎

Watches before she designs: FastTravel's kiosk booking and driver app came from hours at Oslo Airport, not from a brief. Named the company. First person Marcin hired for every company he's built. At Domestika, rebuilt the project editor from user research through production. Sociology degree. Mario Party fan — wanna play?

Mateusz Baltyn

Engineering / Payments

LinkedIn ↗︎

Built FastTravel's payment system from day zero — and three years in, he's the one of us who still runs it. Marcin's longest collaborator, since 2015. Proud owner of a long-lived sourdough starter.

Wojciech Janoszek

Product engineer

LinkedIn ↗︎

Works where frontend meets design — and tests every AI design tool that claims to close that gap. At Domestika, owned the standalone frontend app: TypeScript and React, no half-measures. Modernized legacy areas while the rest of the team rebuilt the backend. Before fryga, led a product team at Sprout Social and co-founded an AI fashion-tech startup. Off the clock, an explorer — capturing beauty one photo at a time.

05 The deal

You pay for the sprint. Every sprint compounds.

€5K

per product engineer · per week

The deliverable is working software, every sprint. Some engagements take one sprint, some take ten. Start with the decision sprint: two of us, one week, €10K. You walk away with a plan for the problem you brought us, and the first change already started in your repo — whether or not there's a sprint two.

Every engagement compounds on your side: the AI harness on your codebase, the conventions in your repo, the deploy pipeline. They keep running when we're not in the room. They're yours.

Know your answer? Talk to Marcin →

06 Not a fit

What we won't do.

If that's what you need, we're probably not the right fit.

MVPs

Starting from scratch isn't our work anymore. For a first build, find a technical co-founder.

Staff augmentation

If you need bodies, hire full-time. It's cheaper, and they'll learn your business. A project with us can't quietly turn into staff aug: nothing renews by default. Our FastTravel team went from three to one as the work shipped. Body shops grow inside a client. We shrink.

Filling seats

We're four people, maybe five tomorrow. We don't subcontract strangers to make the team look bigger. If the project needs more hands than we have, we'll turn it down.

Negotiating down

…and then quietly resenting the project. Either the price is right or we don't take the work.

Building whatever you spec

…without pushing back. If the feature is wrong, we'll say so.

Rewrites to the trending stack

We pick technology by what survives, not what's loud this quarter.

↓ but if

Your product is stuck and your team can't unstick it — or you want AI shipping to production, not stalling at the demo. That's what we do.

07 Contact

Talk to Marcin.

If the work fits, we put a team on the first sprint. If it doesn't fit, we'll tell you who might.

01 / The fastest way in

Book a 30-min call

zcal.co/marcino/vcdc ↗︎

02 / Prefer to write?

Email Marcin directly

[email protected] →

— Located

Kraków · the work happens wherever you are

— Currently booking

Q3 2026 · 2 slots available

— Reply time

Within 2 business days · from a real person

08 What we believe

We side with the problem.

Most teams ship the wrong thing for the right reasons: designers protect the experience, engineers protect the code, business protects the numbers — each one right, and the user's problem lost between them. A product is worth building only if it makes someone's life measurably better. Anything else is code that runs.

We work in small teams because quality grows where everyone feels the product is theirs. We tell each other the truth, even when it's uncomfortable. We share what we learn through writing, teaching, and open source. We don't preach any of this — we just work this way.

— Teams

Small. Owned.

— Decisions

Best argument wins. Not the loudest.

— Craft

Simplicity beats clever.

09 Teaching

We show up where people are learning.

Katarzyna taught Interface Design at AGH Kraków. Marcin mentors at 42 Warsaw and writes about AI-assisted coding at rubyonai.com. If you run a university program, a coding school, or a student event and want a workshop or a talk, reach out.

Hard product problems on Rails.

One team. Three problems we recognize.

Three problems. Four engagements.

The codebase had four architectures pretending to be one app.

One airport worked. Then the next four needed it too.

AI finally stuck when the people closest to the customer could ship it themselves.

"How much time do you want to spend on it?"

One call.

A sprint plan.

The work.

Your call.

The four people making the calls.

You pay for the sprint. Every sprint compounds.

What we won't do.

Talk to Marcin.

We side with the problem.

We show up where people are learning.

Hard product
problems on Rails.