Crewli

01

The first decision on this project was a no.

I spent twelve years working as a chef in New York City. My business partner still operates restaurants there.

The original idea was straightforward: replace the binder that sits in nearly every restaurant with something staff could actually use. Recipes, checklists, training documents, vendor contacts, and operating procedures would all live in one place.

The first technical decision came before any code was written. The initial concept was a native mobile app. Instead, the product became a mobile-first web application.

The reason had nothing to do with speed of development. It came down to ownership. I am not an engineer, and I was more comfortable taking responsibility for a smaller technical surface that I could confidently build, maintain, and support over time.

Every technical decision was also a decision about long-term responsibility.

02

The first version organized information. It proved nothing.

Version one contained no database. It was a structured library of information restaurants already had, spread across menus, recipes, beverage guides, employee handbooks, vendor contacts, prep lists, order sheets, and closing checklists.

Those documents already existed. They were simply scattered between a binder nobody opened and a clipboard sitting near the pass.

The question wasn't whether the information mattered. Years of restaurant experience answered that already. The question was whether putting everything in one place changed how restaurants worked.

It didn't.

The first version made information easier to find. It did not help an owner answer the question they cared about most: did the work actually happen?

03

Customer conversations changed the architecture.

The feedback was remarkably consistent. Restaurant owners rarely asked for additional content. They wanted visibility.

• Who completed the closing checklist?
• Who placed that supplier order?
• Was prep finished before service?

One request changed the direction of the product more than any other. An owner asked for a live dashboard showing what was happening throughout the day.

That request exposed a larger problem. A dashboard without live data has no value. Supporting that feature meant introducing a real database and turning Crewli from a digital reference library into an operational system.

In practice, accountability means a record. When a closing checklist is completed or an order sheet goes out, the app writes it to the database with the person who did it and the time they did it. A notification appears on the dashboard, where any manager or owner can see who and when. Nobody types in a claim that the work happened. Finishing the work is what creates the record.

Clock-in works the same way, and it is tied to location. Someone can clock in at the restaurant. They cannot clock in from the train on the way there.

The record is a byproduct of doing the work, not a second task on top of it.

The obvious next step for a product like this is a scoreboard. Points for completed tasks, streaks for a perfect week, a leaderboard by shift. Crewli has none of that, and that was a decision. Restaurant staff are not looking for a game. They are trying to get through service, do the work correctly, and have a record that they did. Scoring the work would also change what the numbers mean, because as soon as completion becomes a score, people start managing the score instead of the shift.

04

Choosing tools I could be responsible for.

Adding a database changed what I was accountable for. Until then, the worst case was a broken page. After it, the worst case was somebody else's data.

A database changed the worst case from a broken page to someone else's data.

Supabase handled the part I did not want to own. Managed Postgres with row-level security meant the guardrails came with the platform instead of depending on me remembering them.

Every client gets a separate Supabase project. No shared tables, no restaurant's data sitting next to another's. The white-label template ships with the database disconnected entirely, so a fresh copy cannot reach a live client by accident.

Access has three roles: staff, manager, owner. What each role can see is enforced in the database, not just hidden in the interface.

Operational logs purge after ninety days through two independent mechanisms, because one of them only runs when a manager opens the dashboard, and I did not want retention to depend on somebody's habits.

Hosting runs on Cloudflare, and that was a pricing decision more than a technical one. At $150 a month per restaurant, hosting comes straight out of margin. Infrastructure that costs almost nothing is what makes that price work.

It also stayed a web app you install to your home screen rather than a native one. No App Store review, no waiting a week to ship a fix during service, one codebase instead of two.

Installing did not go away. It got shorter. A new hire opens a link and taps add to home screen, inside the browser already on their phone. What disappeared is the store: nothing to search for, nothing to download and wait on, no Apple or Google account standing between a person and their first shift. Signing in stayed, because the app is private behind a login. Restaurant turnover is brutal, and every step between hiring someone and getting them into the tool is a step where they give up. Email confirmation is switched off for the same reason. A new hire should not be waiting on a link before their first shift.

To be precise about what that is, Crewli is a partial progressive web app. It has a manifest, so it installs to the home screen and opens fullscreen with its own icon and no browser chrome. It does not have a service worker, so there is no offline mode. Lose signal in the walk-in and the app stops working until you have a connection again.

That gap is a choice, not an oversight. Offline support means deciding what happens when two phones edit the same checklist and reconnect an hour apart. That is a hard problem to get right, and getting it wrong quietly corrupts the exact records the product exists to protect. The part of a native app that actually mattered here was the icon on the home screen and the feel of opening it, and that part cost a manifest file. The rest was worth being honest about not having.

05

The request was chat. The problem was communication.

The most requested feature was in-app group chat. On the surface the request made sense. Every shift depends on information moving quickly between people.

The more important question was whether chat was actually the problem.

Every restaurant already had a group chat running somewhere. A WhatsApp group, a group text, whatever the staff happened to be on. Adding another chat system would duplicate a workflow that already existed, increase the complexity of the product, raise operating costs, and require maintaining realtime infrastructure that was outside what I could safely own as a non-engineer.

The underlying need was much narrower than the feature request. Restaurants needed one place where everyone on shift could immediately see important operational updates.

Instead, I built a live bulletin board, modeled after the physical one already hanging in almost every restaurant. Because it is connected to the operational database, updates appear immediately for every signed-in user.

Today it is one of the most used parts of the product. Restaurants use it for eighty-sixed items, daily specials, service issues, and photos showing what the closing shift left unfinished.

06

Our competition was paper, not software.

Most restaurant platforms help owners manage the business. Crewli helps staff run the shift. That distinction changed how I thought about the market.

Traditional restaurant software focuses on reporting, labor, compliance, payroll, and financial performance. Those products answer questions an owner asks after the work is finished. Crewli answers questions that happen during service.

• Did prep get finished?
• Who completed the closing checklist?
• What items are eighty-sixed?
• Was there a problem the next shift needs to know about?

Those are operational questions, not management questions.

The more important realization came from customer onboarding. None of our six clients replaced another software platform. Every one of them replaced a binder nobody opened and a clipboard sitting by the pass.

That changed how I evaluated competitors. We were not asking restaurants to switch software. We were asking them to replace paper with a workflow they could actually trust.

It changed the sales conversation as well. Against paper, the objection is never about features. It is that nothing has gone visibly wrong yet. The useful answer is to make the cost of the current system concrete. A health inspector arrives and there is no temperature log to show. Nobody is going to read back through two months of ripped-up order sheets to notice a protein has been over-ordered the whole time. Paper does not fail loudly. It fails quietly, and usually months later.

07

The people using the product were not the people buying it.

Crewli has shipped in English and Spanish since the first version. No customer requested bilingual support.

The decision came from experience inside New York kitchens. In many restaurants, the owner reading the invoice speaks English. The people opening the app throughout the day often do not. In some kitchens, about ninety percent of the staff read Spanish instead.

Supporting both languages affected the product far beyond the interface. Every menu item, recipe, checklist, handbook, training document, and operating procedure stores English and Spanish versions. Every restaurant's content is entered twice as part of onboarding, and every future update follows the same structure.

That ongoing cost was intentional. A product built for restaurant owners alone would have ignored the people expected to use it every shift.

08

The pricing came from the business, not the market.

Crewli costs $500 to onboard and $150 per month after that.

The price did not begin with competitor research. It began with understanding the work required to deliver and support the product.

The full onboarding and build takes eight to ten hours. Every restaurant is configured individually, with menus, recipes, checklists, training documents, vendor information, and operational workflows tailored to that location. The client spends about one hour participating in the process.

Ongoing support is predictable because restaurant operations are predictable. Menus change about twice a year. Prep lists usually change with the menu. Closing procedures rarely change at all. That makes the long-term support burden relatively stable.

Competitors typically charge $250 to $500 per month and expect restaurants to configure the product themselves. Crewli takes the opposite approach. The software costs less each month because the service happens up front.

The insight wasn't that restaurants wanted cheaper software. It was that their scarcest resource is attention, not configuration.

09

The first build was my partner's restaurant.

The first version of Crewli was built for one restaurant, my business partner's. Everything in it was theirs: their name, their colors, their menus, their checklists.

Turning that into a business meant the second client could not cost what the first one did. So the branding and content came out, and what was left became a white-label template. A single configuration file drives the name, logo, and color palette across all twenty-one pages. Content lives in data files. Onboarding a restaurant became configuration instead of construction.

I also wrote the onboarding down: what to collect from a client, where each piece goes, and what to verify before going live. That document exists because I was onboarding from memory, and memory does not scale to six.

10

Where it stands today

Six restaurants run Crewli. Three of them pay for it. Every one of them arrived from paper.

The bulletin board, the feature built instead of the one that was asked for, is posted to daily. Specials, eighty-sixed items, service problems, and photographs of what the closing shift left undone. Staff arriving for a shift know what happened on the one before it.

12

The biggest product decision is still ahead of me.

Restaurants understand Crewli quickly. Explaining the product has never been the difficult part. The friction appears when the conversation reaches pricing.

The current model is $500 up front, followed by $150 per month. The client spends about one hour. The full onboarding and build takes eight to ten.

The barrier is not effort. It is the shape of the first payment.

The clearest evidence for that is my own behavior. Every paying restaurant so far has had its onboarding fee discounted in order to close. Not one of them has needed a discount on the monthly price. The number that stops people is the one they have to pay before anything exists.

Today, onboarding reduces effort instead of reducing cost. My business partner visits the restaurant in person and scans their existing binders and documents in under an hour, which gets the build roughly ninety percent of the way there with almost no work from the client. That approach works because he is physically in New York. It is not a model that scales everywhere.

The pricing question remains open.

• Should the $500 onboarding fee stay as it is?
• Should it be spread across the first months?
• Should it become a higher monthly price with a longer commitment?

Each option changes cash flow, customer expectations, and the economics of the business. I have not made that decision yet, because I do not have enough evidence to believe one answer is clearly better than the others.