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're four product engineers. We work with product companies past MVP — the ones whose codebase, team, or AI rollout needs more than they can ship alone. Rails and AI are our engine. We work in two-week sprints, you keep everything we build, and you can stop after any one of them.

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. We come in, read the mess, and decide what to kill — instead of writing more code on top of it.

→ 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. We come in for the architecture decisions and stay long enough to make them hold.

→ FastTravel

03 / Ship with AI

"AI isn't sticking."

Pilots ran. Demos happened. Delivery looks the same. AI sticks when the people closest to the customer can ship the code themselves — and your codebase stays safe while they do.

→ 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. We 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 we 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 — and we still run the payments, three years in.

Marcin Ostrowski · Katarzyna Kukułka · Mateusz Baltyn

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

10% in demos, 2–3× in production. The difference is who ships.

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 every AI coding approach on the market and built the workflow from what held up. Now a CPO with zero engineering background writes product specs against a codebase the AI knows; agents write the code; Marcin makes the calls. Two people, part-time, shipping to production daily for seven months — more output per week than a full-time developer produced in a month before.

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.

RailsAI harness

7+ mo AI in prod, daily

A CPO who couldn't touch the codebase ships without us in the room.

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

Week one doesn't start with code. It starts with decisions.

Sprint one is the decision sprint. We talk to your team, read the codebase, map the mess — and before we write a line, we tell you what we'd kill, what we'd keep, and what we'd build first. The rest of the sprint ships the first of it: the map comes from doing, not talking. You decide whether that matches your priorities, and whether there's a sprint two.

— 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.

Scope, price, and what ships are all agreed before we start. Two weeks per sprint. No surprises.

— 03

The work.

Direct access to whoever's doing it. No standups to schedule, no project managers in the middle. At the end of two weeks, something ships.

— 04

Your call.

Continue, pivot, or stop. Everything we build is yours. The work earns the next sprint, not a contract.

One sprint is the decision unit; the engagement runs as long as the work earns it — Domestika was eleven months, FastTravel is three years and counting.

We pick up the phone and answer on Slack. When something breaks at 3pm on a Friday, we fix it Friday, not Monday. Four people means no handoffs, no "let me check with the team," no vanishing into a process.

When the work stops earning the next sprint, you keep what we built and we move on. No multi-year contracts, no exit clauses. We're a Kraków team with Norwegian co-owners at Rubynor; we've shipped in both markets and can open doors in either.

Start with the one call. Book it →

04 Team

The four people making the calls.

No handoffs, no bench — these are the people who'll be in your codebase. Which two 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 scope of the task. Writes about AI-assisted coding at rubyonai.com. Mentors at 42 Warsaw.

Katarzyna Kukułka

Product engineer

LinkedIn ↗

Went to Oslo Airport before designing a single screen. She watched passengers fumble, talked to drivers between fares, sat with support staff. The kiosk booking and driver app came from what she observed, not what a brief described. Named the company. First person Marcin hired for every company he's built. At Domestika, rebuilt the project editor from user research through production. Taught Interface Design at AGH Kraków. Sociology degree. Mario Party fan — wanna play?

Mateusz Baltyn

Engineering / Payments

LinkedIn ↗

Built FastTravel's payment system from day zero. Invoicing, billing, corrections, automatic passage fees across the five biggest airports in Norway. 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.

Every month, AI makes a small team faster. We price the sprint, not the hours: when we get faster, you get more.

€20K

per sprint · 2 weeks · 2 product engineers

Scope defined upfront. Working software at the end. Some engagements take one sprint, some take ten; you decide at the end of each one. Start with the decision sprint: one sprint, one price, and you walk away with the kill / keep / build map of your codebase — 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.

It compounds on ours too — with a hard line. Your code and what we learned about your product stay in your repo, full stop. The harness we build in the open: the conventions are public on GitHub, the lessons end up on the blog. That's why every sprint we get sharper, and why you pay the same and get more.

Want the scope conversation? Talk to Marcin →

06 Not a fit

What we won't do.

If that's what you need, we'll save you the call.

MVPs

If you're starting from scratch, we're not the right call. 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.

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 say so.

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.

Stack migrations

To whatever framework is trending this quarter. We pick technology by what survives, not what's loud.

↓ but if

Your product is stuck and your team can't unstick it — or you want AI that delivers 2–3× in production, not 10% in demos. That's what we do.

07 Now booking · Q3 2026 · 2 slots available

Talk to Marcin.

If the work fits, we put two product engineers on a two-week scope. 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're the problem to your solutions.

A product is worth building only if it makes someone's life measurably better. Anything else is just code that runs. Most teams ship the wrong thing for the right reasons — designers protect the experience, engineers protect the code, business protects the numbers. That gap between good intentions and the right outcome is the one we exist to close.

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 — the knowledge isn't ours to hoard. 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.

10% in demos, 2–3× in production. The difference is who ships.

Week one doesn't start with code. It starts with decisions.

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're the problem to your solutions.

We show up where people are learning.

Hard product
problems on Rails.