You have probably typed "client login" into a notes app at some point. Maybe after a week of texts about scheduling. Maybe after the third payment link that got lost.
The idea is sound. The trouble is the blank page. This is the method we use to turn that idea into a plan for how to plan a client portal for a small business, with a build that fits inside a quarter.
Is a client portal right for your business?
Not always. A portal earns its keep when the same handful of exchanges happen again and again, with the same people, and you are the only one handling them.
Ask three questions:
- Do clients come back, week after week or month after month?
- Do you answer the same questions in text threads?
- Is money, paperwork or scheduling spread across three or four tools?
Three yeses, and you should keep reading. If you see each client once a year, a good contact form and an invoice are enough. Be honest about that. A portal is a small piece of software, and software needs care.
Which repeated tasks eat your week?
Start with a list, not a feature wish. For one normal week, write down every time you stop your real work to do admin. Booking. Chasing a payment. Moving a session. Sending a note home. Answering "what time is it again?"
Do not edit yet. Just collect.
This is how Moore Prep started. Lana Millard is one teacher in one small room in downtown Wake Forest. Behind the quiet front of that practice, she was handling scheduling, payments, cancellations, reminders and notes home. Most practices like hers juggle a booking app, a payment link, a spreadsheet and a text thread. The list of juggled tools was the brief.
Count each task by how often it happens and how long it takes. The top three are your portal.
What should clients be able to do without you?
Sort the list into two piles. Tasks that need your judgment, and tasks that only need a clear form.
Signing an agreement needs no judgment. Paying by card needs none. Asking for a time needs none, as long as it is only a request.
In the Moore Prep portal, an approved family can do three things on their own:
- Sign the parent agreement
- Buy sessions by card through Stripe
- Request times
Siblings share one bundle, because that is how families actually think about it. Notice the verbs. Sign, buy, request. Nothing in that list commits Lana to anything she has not seen.
Why should you keep approval of requests in your own hands?
Because your calendar is not a public resource.
The tempting design is full self-service, where clients grab any open slot. It sounds efficient. In practice it hands your week to whoever clicks first, and you lose the chance to protect a day, a break or a family that needs a particular hour.
So clients request. You confirm. At Moore Prep, families request times and Lana confirms them. She stays the teacher, not the system administrator.
The same logic applies at the door. Moore Prep's portal is for approved families only, and the only way in is a free 15-minute call. No family pays for anything before a conversation. Your portal should reflect who you actually want to work with.
How do you make sure the numbers always add up?
If your portal handles prepaid sessions, credits or refunds, decide early how the balance is tracked. This is the part that quietly breaks small systems.
Moore Prep keeps every family's sessions on an append-only ledger. Purchases, bookings, cancellations and refunds are all recorded as entries, never overwritten. That means two approvals can never spend the same session, and the totals always reconcile.
You do not need to say "ledger" to your developer. You do need to say: "If I approve two requests at once, the balance must still be right." Write that sentence in your plan.
Also write your cancellation rule in one line. Moore Prep's is plain: cancel 24 hours ahead and the session goes back on the account automatically. A rule that short can be built exactly as written.
How do you plan the owner's side on a phone?
Most portal plans fail on the owner's side. Everyone designs the client screens, then you get a dense admin panel built for a desktop you never sit at.
You work between appointments, standing up, one thumb free. Plan for that first.
Lana's back office is phone-first, organized around her day:
- Today
- The calendar
- Requests
- Payments
- The waitlist
- Messages
She also has a session assistant. She dictates or types her notes, and it turns them into a draft note home. She edits it, and nothing goes out until she says so. That last clause is the point. Automation can save you the typing without taking the final word.
If you want to explore that kind of help, our AI and automation work is built on the same rule: a draft, never a send.
What sensitive information needs extra care?
Make a list of what your portal will hold before you design it. Names, children's goals, payment history, health or learning notes, signed agreements. Each deserves a decision about who sees it.
A few practical rules:
- Collect only what you will use.
- Let card details live with the payment processor, not in your database.
- Decide what a client can share, and make sharing deliberate.
Moore Prep's progress reports show the last one well. Each child has goals, notes home and a progress report. A family can share that report with a classroom teacher by private link, which means the parent chooses who sees it. The portal also produces a year statement for taxes and benefits accounts, so nobody digs through email in April.
If the data concerns children, health or money, slow down here. It is cheaper to decide now than to rebuild later.
How do you phase the build so it launches sooner?
Cut the plan into loops. A loop is something a client can do start to finish.
A sensible first version for most solo operators:
- Approved clients log in
- They sign your agreement
- They pay
- They request a time, and you confirm it from your phone
That is one complete loop. It replaces the most painful juggling and it is small enough to finish in a quarter.
Phase two can bring notes, goals and shareable reports. Phase three can bring the waitlist and year statements. Each phase should be usable on the day it ships.
The trap is launching nothing until everything is ready. Real clients show you what to build next better than any planning session will.
What questions should you ask a developer before you start?
Bring your task list and take these into the first conversation:
- Which of my repeated tasks does phase one remove?
- Where does the money flow, and who holds card data?
- How do you keep balances right when two things happen at once?
- Can I run my side from a phone?
- Who can see what, and how do I change that later?
- What do I own if we stop working together?
A good developer answers in plain language and pushes back on scope. A bad one says yes to everything. If you want a studio that builds this kind of thing, our custom web development team does, and the Moore Prep case study shows the finished result.
Your next step this week
Do one thing before Friday. Keep a running list of every admin interruption for five working days. Note the task, the time it took and who asked.
At the end, circle the three that repeat most. That page is your portal plan, and it is what we would ask you to bring to a first conversation at /get-started.