From Side Project to Production: Shipping Software with Two People

Sean: We run a software studio. We ship production apps for clients. We build our own products. And we're two people.

Caitlin: Two people who are married, work from home, and share an office that used to be a guest bedroom.

Sean: The guest bedroom thing is important context.

People ask us all the time: "How do you get anything done?" The assumption is that you need a team. A project manager. A designer. A QA person. A marketing lead.

We're here to tell you: you don't. But you do need systems.

#Division of labor (or: why we don't step on each other's toes)

Here's how we split the work:

#Sean handles:

• All code (frontend, backend, database, infrastructure)
• Technical architecture and decisions
• DevOps and deployment
• API integrations and third-party services

#Caitlin handles:

• Client communication and scheduling
• UI/UX design and feedback
• Copy and content strategy
• Project scoping and prioritization

#We both handle:

• Strategy (what should we build, and why?)
• Product decisions (what does "done" mean for this feature?)
• Marketing and sales (we're terrible at both, but we're learning)

Caitlin: The key is that we don't blur these lines. I don't write code. Sean doesn't schedule client calls. When we try to "help" with each other's work, we just create more work.

Sean: The one exception: design feedback. Caitlin designs. I implement. But I'll flag things that are technically hard or slow to build. That feedback loop is critical.

#Tools that actually help

We're allergic to process. But we're not anarchists. Here's what we use:

#Linear (task management)

We tried Notion. We tried Asana. We tried Trello. Linear is the only one that doesn't make us want to quit our jobs.

Why it works:

• Fast. Like, actually fast.
• Keyboard shortcuts for everything.
• No busywork (no daily standups, no status reports).

We use it for:

• Client project tasks
• Internal product backlog
• Bug tracking

Caitlin: I live in the roadmap view. Sean lives in the active sprint. We sync once a week to reprioritize.

#Figma (design)

Caitlin designs in Figma. Sean builds in code. It's a clean handoff.

Caitlin: I don't design full comps for every screen. I design the "hard parts"—complex interactions, new patterns, anything Sean hasn't built before. Everything else, he just builds from a rough sketch or description.

Sean: This is key. If you over-design, you waste time. If you under-design, you waste more time going back and forth. The trick is knowing what needs a comp and what doesn't.

#Slack (DMs only)

We use Slack, but only to DM each other. No channels. No threads. No bots.

Why? Because we sit 6 feet apart. If it's complicated, we just talk.

Caitlin: Slack is for: "Can you look at this?" or "Client just emailed, need a timeline." That's it.

#GitHub (version control, obviously)

Sean's the only one who pushes code, so there's no merge conflicts. But we use GitHub Issues for bug tracking and GitHub Projects for long-term planning.

Sean: I also use it as my "second brain." If I think of a feature idea at 10 PM, I open an issue. Otherwise I'll forget by morning.

#Cal.com (scheduling)

Caitlin runs our calendar. Clients book calls through Cal.com. It syncs to our shared Google Calendar. We block out focus time so we're not constantly interrupted.

Caitlin: The number one mistake small teams make is not protecting their deep work time. If you're in calls all day, you're not building anything.

#When to say no

This is the hardest lesson. When you're small, every opportunity feels like it might be The One. A client wants a feature. A product idea sounds promising. A potential partnership "could be huge."

Here's what we've learned:

#Say no if:

1. It's outside our expertise. We build web apps. We don't build mobile apps, desktop apps, or blockchain anything. Stick to what you're good at.

2. The timeline is insane. "Can you build this in two weeks?" No. We can build a version in four weeks that you'll actually be happy with.

3. The scope is vague. If a client can't articulate what success looks like, the project will never end.

4. You don't like the client. Life's too short. We're a two-person team. If we don't enjoy working with someone, it poisons everything.

Caitlin: That last one sounds harsh, but it's true. We've fired clients. It's always the right decision.

#Say yes if:

1. It plays to our strengths. We're great at: fast MVPs, modern web stacks, clean UIs, offline-first architecture.

2. The client knows what they want. Not every detail, but the outcome. "I need to reduce manual data entry" is a good problem. "I need a platform" is not.

3. We can ship something valuable in 4–8 weeks. Any longer and scope creep kills you.

4. It's fun. We're small enough to choose projects we actually want to work on.

#Why constraints force creativity

Here's the thing about being a two-person team: you can't brute-force problems.

A 10-person team can throw bodies at a problem. They can parallelize work. They can have one person researching while another prototypes while another builds.

We can't.

So we have to:

• Choose boring tech. We don't have time to learn new frameworks mid-project.
• Reuse patterns. Every project builds on the last one. We have a library of components, a preferred stack, a deployment process that just works.
• Ship MVPs. Version 1 doesn't need every feature. It needs the right features.
• Automate relentlessly. If we do it twice, we script it.

Sean: The constraint is actually liberating. We can't over-engineer because we don't have time. We can't gold-plate because we're the only ones building.

Caitlin: And because we're small, we can pivot fast. A 10-person team needs meetings to change direction. We just talk for five minutes and do it.

#What we'd tell other small teams

If you're trying to ship software with a small team (or solo), here's what we'd say:

#1. Specialize, don't generalize

We're not a "full-service agency." We're not "technology consultants." We build modern web apps with Next.js and React. That's it. The narrower your niche, the easier it is to be great at it.

#2. Protect your focus time

Block out half your day for deep work. No calls. No Slack. Just building.

#3. Ship weekly, not monthly

If you're not deploying at least once a week, your feedback loop is too slow.

#4. Build for maintenance

You're going to maintain this code. Future you will either thank you or curse you. Write the README. Comment the weird parts. Use boring tech.

#5. Say no to most things

You can only do a few things well. Pick those things and ignore everything else.

#6. Take breaks

We shut down at 5 PM. We don't work weekends. If you burn out, the whole company burns out.

Caitlin: That last one is non-negotiable. We've built Forever Frameworks to be sustainable. Not "hustle until we're rich." Just… sustainable.

#The best part

The best part of being a two-person team? We can make decisions in real time.

Client wants a feature? We scope it in 10 minutes.
Design isn't working? We pivot in 20 minutes.
Bug in production? We fix it in an hour.

There's no process. No bureaucracy. No "let me run this up the chain."

Just: "Should we do this?"
"Yeah."
"Cool, I'll build it."

That speed is our unfair advantage. And it's only possible because we're small.

Sean and Caitlin Cotter run Forever Frameworks, a two-person software studio. They've been working together since 2021, married since 2015, and arguing about color schemes since roughly 2015 and a half.