One login for the whole shop

When you sign up for bike.co you get an erp.io workspace. That is one account for your shop, one list of people who work there, and one login that opens every module you have switched on. Your front counter, your head mechanic and your bookkeeper all sign in at app.erp.io and move between modules from the same rail on the left. Nobody keeps a second password for the books or a third one for the phones.

There are sixteen modules in the suite today. Service is the one bike.co is built around: the quotes, work orders, week schedule, time clocks, invoices and checklists that make up a repair shop, with parts and card payments still to come. The other fifteen already run as their own products for other businesses, and they plug into the same workspace. A shop that only wants the bench side can run Service alone. A shop with three benches, a van and a fleet contract can add the phones, the CRM and the books without starting over somewhere else.

Each module keeps its own data and does its own job. Service owns the work. The CRM owns the people and companies you do business with. Accounting owns the ledger. Sign owns the signatures. That split is deliberate, and it is written into the Service plan: Service calls the other modules rather than keeping a second copy of their data, so a customer is one record, not three that slowly drift apart.

In a bike shop, almost everything starts and ends with a repair. A rider calls to ask about a bleed. They drop the bike off on Saturday morning. A mechanic runs the safety check, finds a worn chain and a cracked hanger, and the counter calls for approval. The bike goes back on the stand, comes off, gets paid for and goes home. Every one of those moments touches another part of the business: the phone, the customer record, the signature on a quote, the invoice, the deposit in the bank.

So Service is the hub, and the other modules are spokes. What exists in Service today runs from request to invoice: a Requests inbox, numbered quotes with optional lines, jobs with one or more visits, a week schedule, technician time tracking with weekly approval, invoices billed from the finished job, monthly reports, and checklists with photos, signatures and a PDF that can be required before a visit closes. The field app installs from the browser and keeps working with no signal, which is new. Parts, card payments, bike records and the links from Service into the other modules are on the roadmap, and the plan already names which module each one hands off to.

That means the connections are designed before they are built. Quotes will be approved through the Client Portal and signed through Sign. Invoices will post to Accounting. Payments will be matched to bank deposits by Pey. Phony will book repairs against Service availability. Each module page on this site says plainly which half is live and which half is waiting on that connection.

Start with Service, because that is your bench. Quote the work, turn approved quotes into jobs, book the visits onto the week, have mechanics clock their time and bill the job when every visit is closed. Build your tune-up, safety and e-bike checklists, give each person the role they need, and hand customers a PDF of what was checked and what was found.

Then look at the phone. If the counter loses an hour a day to "is my bike ready?" and "do you have time for a wheel true this week?", Phony is the second module most shops will want. It answers from a knowledge base you control, puts the caller through to the counter when a person is needed, and books a callback rather than letting the call ring out. The third is usually Accounting, so the books live in the same workspace as the work.

After that it depends on the shop. A rental or corporate fleet operator will want Sign for agreements and the CRM for account contacts. A shop chasing Google reviews will add Marketing. A group with two locations and a lender asking about cash will add CFO. None of that has to be decided on day one, because every module is included in the 30-day trial.

A solo mechanic who wants checklists and an AI receptionist is on two modules, Service and Phony, which fits Starter. A small shop running Service, Phony and Accounting is on three, which needs Growth; Growth then leaves room for two more, and because CRM and Marketing share one slot, adding both of them uses only one.

A growing shop with Service, Phony, Accounting, CRM and Marketing, Sign, Chat, CFO and Pey is on eight modules, which is Scale territory, and Scale also covers fifty people and white-label. You can change which modules are switched on at any time. Turning one off does not delete what is in it.