The stack at a glance
| Layer | What it uses |
|---|---|
| Server | Laravel on PHP 8.3 or later |
| Data | MySQL 8 or MariaDB 10.6 |
| Web app | Livewire dashboard |
| Operator console | Filament |
| Phone apps | Flutter 3.32 or later, with one codebase serving both platforms |
| AI vendors | OpenAI, Google Gemini, Anthropic, and Stability, chosen per workflow |
| Payments | Stripe |
| Optional extras | Firebase push, SMTP or a similar email service, a support chat widget |
A lens for reading it: five control planes
| Plane | Question it answers | Where it lives in Polymath AI |
|---|---|---|
| Persona | What is this assistant? | Expert records: instructions, model, temperature, look, roster |
| Meter | Who may use it, and what does a reply cost? | Plans, credits, referral rewards, Stripe |
| Identity | Who is this person on this device? | Accounts, web sessions, phone tokens, email codes |
| Delivery | How does the answer reach them? | Live streaming, response cards, voice, uploads, images, history |
| Governance | How does the operator steer all of it? | Filament console, branding, announcements, safety layer, installer |
Customizing the server side is a job for Laravel development skills, and the phone apps call for Flutter app development experience.
Persona plane: an assistant is a row in a table
What the product provides. The roster holds fifteen specialists, including health information, legal information, tutoring, trip planning, data analysis, cooking, coding, and writing. Each record stores the assistant’s job description, its instructions, which vendor and model answer for it, the temperature, a price in credits, its colors, and optionally the plan a user needs. Conversations never mix across experts.
Engineering reading. When an assistant is data, the roster can change on a Tuesday afternoon with no deployment. Routing is the second benefit: because the vendor and model sit on the record, a quick-lookup assistant can run on a small, cheap model while a data analyst runs on a stronger one. The cost of this flexibility is that a prompt edit changes product behavior instantly, for every user, with no review step.
Operator takeaway. Keep a changelog of who edited which prompt, price, or model, and when.
Meter plane: credits connect plans to vendor bills
What the product provides. Administrators create plans and sync them to Stripe. Some experts can be reserved for certain plans, and every expert carries its own credit price. Renewals top up credits. The platform applies charges so that parallel requests cannot draw on the same credits twice, and a reply that fails is refunded without any manual step. Before a Stripe event is allowed to alter anything, its signature is verified, and the platform also handles a grace period that begins once a plan’s paid-through date has passed. Referral rewards stay off until an operator turns them on. Once active, a reward can fire when someone registers, verifies their email, or makes a first purchase; a monthly ceiling limits abuse, and the database itself rejects duplicate rewards.
Engineering reading. Three hazards sit in this plane: double spending, charging for failures, and replayed payment notifications.
- A balance check followed by a separate deduction lets two parallel requests both pass the check. Locking the balance row inside a transaction closes that gap, and Laravel's query documentation notes that the transaction also releases the lock if something fails midway.
- Payment notifications can show up twice or in the wrong order. Stripe's webhook guidance is to confirm the signature on the untouched request body, remember which event IDs were handled, and avoid relying on arrival order.
- A refund path only works if every failure route leads to it, including a stream that drops halfway through a reply.
Operator takeaway. Once a month, compare credits issued and consumed against the invoices from each AI vendor, so a mispriced expert shows up early.
Identity plane: one account, two kinds of login
What the product provides. People can sign up, sign in, and reset passwords on their own. New accounts are confirmed with a one-time code sent by email. Browsers use web sessions, while the phone apps hold tokens in the operating system’s protected storage: Keychain on iOS and Keystore on Android. A password reset signs the person out of every other session on web and phone.
Engineering reading. Browsers and native apps handle login differently, so forcing one mechanism on both usually weakens one of them. Giving each platform its own credential type, both resolving to the same account row, lets the plan and credit logic run exactly once. The sign-out-everywhere behavior after a reset matters most when a phone is lost.
Operator takeaway. Rate-limit sign-in and email-code attempts, and give phone tokens a finite lifetime.
Delivery plane: getting the answer onto the screen
What the product provides. Replies appear as they are generated, on web and on phone. Certain experts show a custom card in place of plain text: a cooking reply becomes a checklist with counters, a data analysis reply can draw a chart, a translation shows two languages side by side, and a travel plan becomes day cards on a timeline. The phone app adds spoken input, read-aloud playback, and file uploads in supported workflows. Both clients include an image studio and a saved gallery, and image generation is also available from the phone. Transcripts are saved to the account, stay in sync across devices, and can be exported. The web dashboard also covers profile settings, notifications, invitations, language, and theme, and the interface is available in Arabic (right to left), English, French, German, Portuguese, and Spanish.
Engineering reading. Streaming improves how fast the product feels, and cards only work if the client can predict the shape of what arrives. That points to a strict schema per card type, checked on the server, with plain text displayed instead whenever a reply does not fit.
Operator takeaway. Test on a slow connection and with a deliberately interrupted reply before launch.
Governance plane: where the operator steers
What the product provides. The Filament console covers the expert roster, plans, credit balances, user accounts, referrals, announcements, legal pages, vendor keys, and branding. The product name, slogan, logo, icon, and brand color appear across the web app and the public landing page, and the phone app downloads them from the server each time it opens, so routine rebranding avoids a new store build. Announcements can go to everyone, to one plan, to users of one expert, or to named people, over web, phone, push, or email. The public landing page lists whichever experts are currently enabled. Setup runs through a guided installer in the browser, which audits the server, wires up the database, handles activation, and creates the first admin account.
Sensitive experts, such as health and legal, can carry disclaimers and safety instructions that the server appends to the prompt. Changing the prompt text shown in the console cannot remove that layer.
Engineering reading. Appending safety text on the server keeps the guardrail outside the content an operator edits day to day. It is still a guardrail and not a guarantee, so it should sit alongside on-screen disclaimers and adversarial testing. Anyone building a dedicated AI legal assistant meets this same question. If you also need a review trail for changes an AI proposes, our write-up on traceable AI change approval covers one approach.
Operator takeaway. Treat disclaimers as part of the interface, not only as text inside the model’s instructions.
One request, followed across the planes
Trade-offs worth weighing
| Decision | What you gain | What to watch |
|---|---|---|
| Per-expert credit prices | Price tracks each vendor's cost | More numbers to maintain, and users may wonder why replies differ in price |
| Rules enforced in one backend | Web and phone cannot disagree | The backend becomes the one place that must stay up |
| Separate web and phone credentials | Each platform uses its native secure storage | Two kinds of session to audit |
| Safety text added on the server | Operators cannot delete it by accident | Does not replace testing or human review |
| Stripe-hosted checkout and billing portal | Less payment interface to build | Less control over the exact flow |
| Experts as editable records | Fast iteration | Mistakes go live immediately |
| Self-hosting | You choose where data lives and what it costs | You also own patching, backups, monitoring, and uptime |
Worked example: pricing a three-expert lineup
| Writing helper (light model) | Travel planner (mid model) | Data analyst (heavy model) | |
|---|---|---|---|
| Vendor cost per reply | 1 unit | 2 units | 5 units |
| Credit price | 1 credit | 2 credits | 3 credits |
| Revenue at 2 units per credit | 2 units | 4 units | 6 units |
| Margin per reply | +1 unit | +2 units | +1 unit |
Acceptance checks before launch
| Check | Pass condition |
|---|---|
| Send two requests at once when credits cover only one | One goes through, the other is declined, and the balance never dips below zero |
| Kill a reply partway through | The charge is reversed and the user sees a clear message |
| A subscriber on a cheaper plan opens an expert reserved for a pricier one | Blocked before any vendor is called |
| Replay the same Stripe event | Credits are added once |
| Send a webhook with a bad signature | Rejected, balance unchanged |
| Reset a password | Other web and phone sessions stop working |
| Rewrite the prompt shown in the console for a health expert | The server-added safety instructions are still sent to the model |
| Submit the same referral twice | One reward only |
| Change the branding in the console | The phone app picks up the new look the next time it opens, with no new build |
| Return a malformed card payload | The screen falls back to plain text |
