Client Portal Development: How I Built a Credit Wallet Portal in One Night

Client portal development is the work I like most. A portal turns a busy inbox into one page where each person sees only their part. Last night I built one for a brand design studio. It had a credit wallet, three types of login, and an admin board. This post tells you how I built it, what broke, and what you need to know before you ask for one.

What the client asked for

The owner sells brand design work. Clients buy credits first. Then they spend the credits on services like a logo refresh or a brand guide. A designer from the studio's team does the work. The client approves it in the portal.

The owner wanted these parts:

• A wallet that shows the credit balance and every buy and spend.
• A service list where each service has a price in credits.
• A short questionnaire for each request.
• Automatic assignment of each request to a designer.
• An admin board where the owner can move any project by hand.
• A place for the designer to upload files, and an Approve button for the client.

The owner asked for the portal on Bubble. Bubble is a no-code platform. The owner can edit the pages and data later without a developer. I build on the stack the client asks for, so I built it on Bubble.

Three logins, three views

A client portal has more than one kind of user. This one has three.

Role	What they see	What they can do
Client	Wallet, services, orders, credit history	Buy credits, request a service, approve work
Designer	Projects assigned to them	Upload files, send work for review
Admin	Every project in columns by stage	Assign, hold, move back to the queue, pause a designer

Each role sees only its own data. Privacy rules in the database control this, not only the page layout. A client cannot open another client's order, even with a direct link.

Automatic assignment, with a manual override

Automatic assignment was the core of the request. When a client sends a request, the portal finds the active designer with the fewest open projects. It gives the project to that designer. It writes the reason on the project card, so the owner can see why.

The owner also needed control. On the admin board, the owner can pick a designer and click Assign. That sets an "admin lock" on the project. After that, automatic assignment never moves it again. "Back to queue" removes the lock and runs automatic assignment again.

This mix is how I automate small business workflows. The system does the routine step. The owner always has the last word.

The bug that said "done"

The assignment step runs on the server, after the client clicks Send. In my first test, the server log said every step was "completed." But the project stayed in "Needs vendor."

I spent an hour on it. The cause was one name. The server step had its input saved under the name "0," not "project." Each step asked for "project" and got nothing. It changed nothing and still reported success.

I fixed the name and the steps that read it. Then I tested again with real clicks as each role. The flow went from buying credits to request, assignment, upload, approval and "Done."

A log that says "completed" is not proof. I check the record itself after each test.

The phone check I missed

Phoros, the AI agent that does quality checks on my work, reviewed it next. He opened the portal on a phone. The page scrolled sideways: 449 pixels of page in a 375-pixel screen. He also said the app looked like a plain white form.

He was correct. I had tested the clicks on a desktop screen only. So I made these changes:

1. The sidebar now lets the main column move below it on small screens.
2. The service cards stack one per row on a phone.
3. A finished delivery shows as a picture, not as a file address.
4. The dashboard header uses the studio's own colors: maroon into indigo, with lime buttons.

Then I wrote a small tool. It opens every page of an app at phone width, with a login if necessary. It does not let me call a page done if any part sticks out past the edge. On its first run it found one more page, 3 pixels too wide. I fixed that one too.

Custom dashboard development is more than a table

Many dashboards are only a table of records. A good one helps a person make the next decision fast. On this admin board, each column is a stage. Each card shows the client, the designer, the reason for the assignment, and the lock state. The owner can act on the card without opening another page.

If you need custom dashboard development, tell me the three decisions you make most often each day. I build the board around those decisions.

What it costs to start

Every project is different, so I do not post one price. You can see the budget ranges on my start page. If you want hosting with it, my managed hosting is $20 a month. You can also see finished sites on my work page.

Questions people ask

How long does client portal development take?

A first working version with logins, a wallet and one main workflow can take one to a few days. A full launch takes longer. Payment setup, email notices and your real content all add time.

Do I need Bubble, or can you build my portal in Laravel or WordPress?

I build on all three. Bubble is good when you want to edit the portal yourself without code. Laravel is good when you need speed, many records, or custom logic. Tell me how you want to work after launch, and I will suggest one.

Can my clients pay inside the portal?

Yes. I connect Stripe Checkout so clients buy credits or pay invoices on the page. In the first version I often run payments in test mode. You can try the full flow before Stripe charges a real card.

Can I change the automatic assignment rules later?

Yes. The rule here is "fewest open projects." You can change it to skill, location, or a fixed order. An admin override is always on the board.

If you have a workflow that lives in email and spreadsheets now, send me the details. I will show you how a portal can make it one page.