- Product
- Perch, a booking and client app for solo service businesses, the kind of tool a massage therapist, a mobile dog groomer, or a house cleaner uses to run their week.
- What it does
- Clients book online, and the owner keeps client records, sends reminders, and takes payment, all in one place.
- The question
- "We get signups, but they don't turn into paying regulars. Should we build the ai smart-scheduling feature we have planned?"
The outside-in first pass. You get where you stand and what to fix first. It credits toward a Review or the Audit.
Where you stand
What's working
What we found
Security
It's about who can reach your customers' data and your paid accounts. It's tempting to picture a hacker who has chosen you, but most attacks are automated programs sweeping thousands of sites for the same few open doors, so to them you're a row on a spreadsheet, and with a door left open it isn't a matter of if it gets used, but when. This is a light look from the outside at the obvious gaps, not a full security test, and it's the same handful of things a partner or a customer checks before trusting you with real data.
Accessibility
The standard here is WCAG, the common measure of whether a site works for people with disabilities, and it isn't a government-only rule. About one in four US adults has a disability (CDC), the ADA has been applied to private companies and not just government agencies (the Domino's Pizza case (opens in a new tab) reached the Supreme Court), and the same fixes help every client, like someone booking in bright sunlight or one-handed on a phone. For a tool like Perch, an inaccessible booking page is bookings every owner loses without seeing why. You can find problems like these yourself with a mock screen reader.
Product
Our recommendation
You asked whether to build the ai scheduling feature. The answer is not right now. You're losing customers faster than a new feature would bring them in, so the items above come first. Nothing here requires a full rebuild. Build the ai once there's booking history to make it any good.
What the Review adds: it confirms the Snapshot's findings and turns up more that only show under real use. It credits toward the Audit.
The findings in detail
Testing the running app by hand confirmed the Snapshot's findings and turned up more.
Security
Accessibility
Product
What the Audit adds: I go into the code, the configuration, and how it's hosted, score each area, show the reasoning and the fix at the code level, and a sequenced plan with a test for each. Whatever you spent on a Snapshot or a Review credits toward it.
This sample shows only a few findings, to give the shape of it. A real audit is far more comprehensive, covering the whole codebase, how it's hosted, and every dependency.
How it scores
Each area is rated Emerging, Developing, Established, or Optimized, from significant gaps to done well enough that others could copy it.
Overall: Emerging, on an established technical base. The engineering underneath is solid. The gaps are in security hygiene, accessibility, and the layer that turns a new owner into a paying regular, and all of it is cheaper to close than the ai feature on the roadmap.
Why it scores this way
Security Most attacks are automated and hit any site with these gaps, so it isn't about being a target. The protections aren't in place, and a key to a paid service is sitting in the page for anyone to copy.
Accessibility The booking controls don't work by keyboard, the text is too faint to read, and the session cuts people off mid-booking with no warning.
Product A new owner can take in only a few new things at once, and the one action that grows the business is the hardest thing to find.
Grounded in the recognized security and accessibility standards, and in decades of research on how people learn and where their attention goes.
What only the code shows
The code, in detail
Two of the fixes, at the code level.
Headers today// no security headers set anywhere in the app
export default nextConfig
The change// set them once, on every response
headers: [{ source: '/(.*)', headers: [
{ key: 'X-Frame-Options', value: 'DENY' },
{ key: 'Strict-Transport-Security', value: 'max-age=63072000' },
{ key: 'Content-Security-Policy', value: "default-src 'self'" },
]}]
A booking slot today<button class="slot">{time}</button>
// low-contrast token, no name a screen reader can read, no focus style
The change<button class="slot" aria-label={`Book ${time}`}>{time}</button>
// passes AA contrast, an accessible name, and a visible focus ring
Where I'd start, in order
The access-control and injection gaps. One customer reaching another's data is the most serious finding here, and it has to close before anything else.
The exposed key, the security headers, and the booking page's accessibility. These shut the openings anyone can find and widen who can book.
The first session and the booking link, then revisit the ai feature. On today's thin booking history it would guess more than it knows, so it is worth building only once there is enough real history behind it.
How you'll know it's working
Confirm one account can't open another's record, re-run the header scan, re-test the flow from a keyboard and a screen reader, and watch how long a new owner takes to reach their first booking. The security and accessibility checks pass or fail plainly, and the time to first booking is the number that tells you the product changes are landing.
Want this for your own product?
Start with a Snapshot, $500, and it credits toward whatever you do next. Bring a question to office hours (opens in a new tab), or ask one free in my Q&A.