Parkside Labs

The Parts of a Startup Nobody Sees

Customers meet the polished product. Keeping it alive is support queues, vendor emails, pricing math, and a hundred small decisions a week.

You always meet a startup at its most polished. The website, the demo, the launch post, the one customer story that went well. Nobody publishes their support inbox, the vendor negotiation that dragged on for a month, or the pricing spreadsheet with four abandoned tabs. Fair enough. Customers shouldn't have to watch the sausage get made, and a good product is supposed to make complicated things feel simple.

But the gap between what people see and what a startup actually does all day is wider than I expected, and I say that as someone who thought he expected it. At Parkside Labs we build Genie in a Book and Genie Comics, which turn a family's photos and story ideas into original printed books. From the outside: upload photos, describe an adventure, review the result, get a book in the mail. From the inside, that flow is the thin visible layer on top of everything else this post is about.

The code was the familiar part

Our background is software engineering, so building the application was the piece we knew how to do. Design the systems, integrate the APIs, ship the features. What nobody's engineering career prepares them for is how quickly the code becomes a minority of the work.

The pattern that took me longest to internalize is that decisions travel. A pricing change isn't a pricing change; it touches the checkout flow, the accounting, the promo copy, and three pages of the website. Adding a new print format sounds like a product decision until it changes page dimensions, shipping costs, design templates, and which kinds of stories physically fit in the book. In software you learn to think about dependencies between services. In a business, the dependency graph includes the tax accountant.

A feature can work exactly as designed and still be a mistake, because it confuses customers, or generates support tickets, or quietly raises the cost of every order. Correct code is table stakes. Whether the change helps the business is a different question, and the code can't answer it.

Edge cases turn into policy

Engineers use "edge case" to mean an unusual input. In a startup, edge cases are how policy gets written.

A customer uploads a photo with four people in it and wants only one of them in the book. Someone needs a book in hand before a birthday that is nine days away. A payment succeeds but a later step in the workflow doesn't. A customer changes their mind after production has started. The first time each of these happens, somebody makes a judgment call. The third time, the judgment call becomes a procedure. Eventually the procedure becomes product: a validation rule, a cutoff date on the order page, a refund policy written down where customers can find it.

Most of the company got built this way, from repeated contact with reality rather than from a plan. The trap is improvising forever. At some point you have to notice you've answered the same question five times and turn the answer into a system, because a business that handles every situation as a one-off is really just a person with a very demanding hobby.

The support inbox is a product roadmap

I used to think of support as the thing that happens after the product is done. It took embarrassingly little time to learn that support is where you find out what the product actually is.

Analytics tell you where people stopped. Logs tell you what errored. Customers tell you why it mattered, and they notice things the team stopped seeing months ago. A question that shows up every week is a missing feature. A misunderstanding that keeps recurring is bad copy on some page I probably wrote at midnight. When the same correction keeps getting requested, the fix isn't to answer faster, it's to make the confusion impossible.

The counterweight is that small companies are dangerously good at building whatever the most recent customer asked for. Do that for a year and the product becomes a pile of exceptions. Support supplies the evidence. Somebody still has to exercise judgment about which patterns deserve to become software.

Quality is a job, not a checkbox

With a normal product you test it thoroughly once, then ship the same thing ten thousand times. A personalized product is a new product on every order. Every book we ship is a variation nobody has ever reviewed before.

So quality had to become a workflow rather than a phase. Does the story make sense? Is the kid recognizable on every page? Do the illustrations match the events? Will this file actually print the way it renders on screen? Software checks the measurable parts. The judgment calls need eyes, and there have to be defined points in the pipeline where eyes happen, or else quality becomes invisible labor done reactively by whoever spots a problem first. That works for ten orders. It does not work for five hundred.

Your vendors are your product

A customer who orders from us is not building a relationship with our print provider, our payment processor, or our shipping carrier. They're building one with us. When printing runs late, the customer experiences us being late. When tracking says a package is in the wrong state, we're the ones who look disorganized.

Partners are also the only reason a team our size can exist. We don't own printing presses or warehouses, and we shouldn't. But every partnership is a dependency, and vendors change prices, deprecate APIs, and adjust production times without asking us. The useful discipline is knowing exactly where you're exposed: which partners could be replaced in a week, which would take a quarter, and which customer promises rest on machinery you don't control. It's architecture thinking, applied to companies instead of services.

Pricing and marketing, briefly, from an engineer

Pricing looked like arithmetic from a distance. Cost plus margin, publish the number. Up close, the number has to cover the easy orders and the hard ones, the reprints, the support time, and the generations that get thrown away, while also telling customers what kind of product this is. Price too low and people assume it's a template book. Too high and you're competing with commissioned art. The number is a positioning statement wearing a dollar sign.

Marketing was more humbling. Engineering gives you tight feedback loops: the test passes or it doesn't. A marketing effort can be smart, well executed, and produce nothing, while some offhand partnership turns into real revenue. The temptation is to respond with volume, more posts and more channels, but attention is the scarcest thing a small team has. The only sane approach we've found is treating it like slow experimentation and accepting that trust accumulates on a calendar measured in months.

Memory doesn't scale

Early on, the founders are the database. We know why the layout works the way it does, which vendor conversation is still unresolved, which customer had that weird order in March. It feels efficient because nothing has to be written down.

It's actually a liability with good UX. Knowledge in one person's head can't be searched, shared, or recovered, and every process that depends on it has a bus factor of one. The quiet transition from memory to written systems, decision logs, documented workflows, an order status a teammate can actually read, is one of the least glamorous and most important things a small company does. Not to create bureaucracy. So the company stops having to rediscover itself every time something recurs.

Momentum hides fragility

Here's the uncomfortable one. A startup can look like it's working while founders personally catch every falling plate behind the curtain. Orders succeed because someone is watching each one. Customers are happy because someone answered at 11pm. That's fine early, and honestly it's the fastest way to learn. The danger is mistaking heroics for infrastructure.

Eventually you have to sort the manual work into two piles: the care that actually makes the product special, which should stay human, and the compensating-for-missing-systems work, which should be automated or designed away. Getting that sort right is, as far as I can tell, most of what "scaling" means for a company like ours.

The product is what people see. The unseen pile is what determines whether they ever see it twice.