Blog

Notes on portals, APIs, and the work between them.

Writing from the same team that ships the automations. Each note is a decision we keep making on client work: why it matters, what to build, how it connects, and where it belongs.

March 12, 2026
Custom GPTs and where they belong in a client workflow
Why
A custom GPT is useful when the team already has a process and a record. On its own it becomes another tab. People paste a brief, wait for a draft, then paste the draft back into the CRM. The model did not save the step. It moved the copying.
What
The GPT should sit inside the portal the team already opens. It drafts the next reply from the live account: the customer, the open order, the last message, and the step your process says comes next. The answer comes from your workflow, not from a blank chat window.
How
Wire the model to the same records as the CRM and the inbox. Give it the fields the API already provides. Keep a person on the send when the workflow says a person should send it. A draft that cannot see the account will sound confident and still be wrong.
Where
Support replies, internal briefs, and the first version of a follow-up. It does not replace the portal. It is one action on the portal, next to the data the action needs.
April 3, 2026
What to connect first when a SaaS product exposes an API
Why
A wide integration that nothing reads is harder to trust than one live field. Teams lose faith when the first release connects ten objects and none of them match the screen they check every morning.
What
Start with the record people copy by hand: the lead, the invoice, or the ticket. That object is the one the portal has to show before anything else is worth connecting.
How
Read it from the API, show it in the dashboard, and confirm the team will use that screen instead of the export. Only then add the side workflows: the follow-up, the alert, the write-back. If the API cannot support the job, the scope should say so.
Where
Any stack where staff keep a second login open just to copy a status into a sheet. Billing, CRM, and support are the usual first connections. Ads and chat follow once the core record is trusted.
May 21, 2026
Client portals that show live data from the tools you already pay for
Why
A portal that stores its own copy of the business becomes a spreadsheet with a login. Someone has to maintain it. The tools you already pay for keep the real record, and the portal falls behind.
What
The portal should read those tools and write back when a person takes an action. Accounts, status, and the next step live on one screen. The source systems stay in place.
How
Next.js screens stay close to the API. Retool is used when a team needs an internal view quickly. The layout only shows fields the connection can actually supply. A missing field is listed as manual, not drawn as if it were live.
Where
The client portal opened each morning, and the internal dashboard used before a meeting. That is the difference between a screen people check and a sheet they maintain.
June 9, 2026
How a handoff moves from a chatbot to a person
Why
Chat can take the first questions. The handoff fails when the person receives a transcript and none of the account data. The customer then repeats the order, and the team opens another tool to find it.
What
The message, the customer, and the open order need to arrive as one record. The person should see the same account the bot was reading, on the channel the team already watches.
How
Connect the site chat, WhatsApp, or ManyChat thread to the portal. Pass the identifiers the API already knows. Show the thread next to the order, the policy, or the listing. A person steps in when the workflow says the question is no longer for the bot.
Where
Retail support, product inquiries, and any inbox where the first reply is automatic and the second reply has to be accurate.
July 18, 2026
GoHighLevel inside a portal you own
Why
GoHighLevel is a strong place to run pipelines and sequences. It is a weak place to ask a client to learn another login just to see where they are.
What
Pipelines and follow-up can stay in GoHighLevel. The portal shows the stage, the next task, and the last message. The CRM remains the system that sends the sequence.
How
Pull those objects through the API into the screen the team already opens. New leads from the site or from ads land in the same pipeline. The portal does not rebuild the campaign tool. It reads it.
Where
Agencies, real estate follow-up, and any account where the client should see progress without a second password.
August 4, 2026
What 15 years of delivery changed about how we scope an integration
Why
A scope that lists logos is not a scope. The useful question is which login should disappear, and which job that login was doing. If the API cannot do that job, drawing the logo on a slide does not help the team on Monday.
What
We write the portal, the automations, and the records that stay manual. The manual list is part of the delivery. It is how the team knows what is still a person’s job.
How
Name the tools. Map the APIs. Build the screen around the records that can stay in sync. Leave the rest written down. The same engineers stay after the first release, because the next workflow is usually an extension of this one.
Where
On the portal the team already opens. The notes stay with the account, so the next workflow extends this one instead of starting from a blank brief.