Agency operations · Project 05
A connected workspace for agency operations.
Panatomics brings an agency website and administrative workflows together. The project migrates the supplied PHP/Laravel application and MySQL data model to a JavaScript Worker backend with Cloudflare D1 storage.
- Role-based login and secure admin sessions.
- CRM leads, follow-ups, CSV import/export and bulk actions.
- Projects, tasks, users and linked operational records.
- Services, pricing plans, invoices and a database-connected welcome page.
PHP / Laravel source · JavaScript Workers · Cloudflare D1 · SQL · Gmail SMTP
Open live preview ↗Live preview loads when this card comes into view.
THE PROBLEM
Context
Agency leads, client context, projects, tasks and service pricing need connected records and clear ownership rather than scattered administrative workflows.
MY CONTRIBUTION
Engineering decisions
- Migrated the supplied Laravel and MySQL application model to a JavaScript Worker runtime with persistent Cloudflare D1 storage.
- Connected role-gated sessions and validated server-side CRUD for leads, users, projects, tasks, services, pricing plans and invoices.
- Mapped service pricing plans to the original welcome-page comparison table.
- Added CSV import/export, bulk actions, follow-ups and linked record views to support everyday agency operations.
SYSTEM FLOW
Conceptual architecture
Public website → authenticated admin / API → relational D1 storage → SMTP transport
Illustrative workflow · Not a production screenshot
OUTCOMES
What changed
- Deployed a public agency website with a database-backed admin workspace.
- Verified create, reload, update and delete flows alongside role restrictions and session security.
- Restored the original welcome layout and mapped all nine saved active pricing plans.
INTEGRATION STATUS
- Gmail STARTTLS authentication is verified; actual inbox delivery has not been tested.
- The AI endpoint is connected, but the external provider still needs its company profile configured for Panatomics.
Public product link appears only when a product URL was verified. Source code is not linked unless a project-specific public repository is verified.
01 / A CLOSER LOOK
Make operational state understandable
Business software is useful when people can tell what needs attention. A lead, task, invoice or learning activity should have a state that means something to the people using it. Ownership, timestamps and linked records help explain who is responsible and why a record appears in a particular list.
Reports should follow those definitions so that a total has an understandable meaning. A dashboard number is less useful if users cannot tell which records it includes or how recent they are. Exports and bulk actions also need access rules and validation, because they can affect many records at once. The relevant case studies describe documented workflows; sample explanations on this page are not live customer data or a claim about current business activity.
02 / A CLOSER LOOK
Change existing systems deliberately
An existing application brings records, users and assumptions that cannot be ignored during a change. A migration should start by identifying the current schema and the operations that depend on it. Adding a field, changing a relationship or moving to a different runtime can affect reports, imports, integrations and earlier records as well as the screen currently being edited.
A useful migration plan explains the intended mapping, the checks that confirm it and the behaviour if some input does not fit the new structure. Representative data and relationship checks help reveal problems before the change reaches ordinary users. Existing private data should be handled only within the authorised environment. A public case study can explain the approach without publishing credentials, password hashes or customer information.
03 / A CLOSER LOOK
Identity, roles and record access
Authentication establishes who is making a request. Authorisation decides which actions and records that identity can access. A hidden button does not replace a server-side permission check: a protected operation must still check the user when a request reaches the application. Record ownership also matters when several teams or clients use the same system.
A role matrix can make the expected behaviour explicit. It should describe who may view, create, update, export or delete each kind of record, including exceptions such as an assigned owner or administrator. Session expiry and sign-out should have understandable outcomes. A review should include a permitted request and a denied request, so the boundary is demonstrated instead of inferred from the interface.
04 / A CLOSER LOOK
Model the relationships before adding screens
A relational model should reflect the relationship between the records people work with. A client may have several projects, a project may contain tasks and an invoice may refer to a service or a customer. Explicit relationships help the application answer questions consistently and reduce the need to copy the same information into unrelated places.
The model also needs rules for change. What happens to linked history when a record is archived? Can two users create the same external reference? Which fields represent the current state and which preserve an event that already occurred? These decisions influence validation, reporting and deletion behaviour. A diagram is useful when it clarifies those questions; a list of tables alone does not explain the business process.
05 / A CLOSER LOOK
Connect clients through a clear API contract
An API contract describes the request a client may send and the response it can rely on. That includes input names, validation rules, authentication, pagination and the difference between a successful operation and a rejected one. Consistency helps a web interface, a mobile application and an external integration handle the same business rules without guessing.
Changes to an established API need to consider existing consumers. Removing a field, changing its meaning or altering an error shape can affect a client that was not part of the latest development session. Examples and compatibility notes make the contract easier to review. The portfolio documents REST API work and integrations; the exact endpoints and access requirements of a live product should be confirmed through its own authorised documentation.
06 / A CLOSER LOOK
Review the complete journey
A screen can appear correct while the underlying workflow is incomplete. A useful review follows a record from its first creation through validation, persistence, reload, later edits and any linked action. It also checks what happens when a field is missing, an external service fails or a user attempts an action that their role does not permit.
The depth of testing should match the consequence of a mistake. An informational layout needs readable content and working navigation; a payment or permission change needs closer checks around state and access. Review notes should make the expected result visible, explain the conditions used and distinguish a verified outcome from a limitation that still needs attention. This is a review approach, not a claim that every historical project has identical test coverage.
07 / A CLOSER LOOK
Share only what the task requires
A professional enquiry usually needs a name, a reply address and enough detail to understand the opportunity. It does not require a production password, a customer database or private payment records in the first message. Examples can often be anonymised while still showing the workflow or the error that needs attention.
The portfolio contact forms save the information supplied so that Raju can review and respond. An external AI service may process assistant messages as described beside the chat controls, so private credentials should not be placed there. Access to an application, hosting account or source repository can be discussed later through an appropriate authorised channel. This keeps the initial conversation useful without exposing information that is unrelated to the brief.
08 / A CLOSER LOOK
Make the next step understandable
A useful delivery includes enough context for the next person to operate the result. That can mean a short explanation of a workflow, where configuration belongs, how a record is managed or which external service is responsible for a particular result. Documentation should describe the application as it is delivered, including anything that remains outside the agreed scope.
Ongoing work may include content changes, bug fixes, performance reviews or new requirements after real use. Those are easier to discuss when the original boundaries and known limitations are recorded. Source access, hosting responsibilities, credentials and support arrangements should be agreed directly for the engagement; the presence of a public project link does not imply permission to access its private administration area.