The Problem No Tool Was Solving for My Agency
Running a web agency for any length of time produces a particular kind of quiet chaos. You start taking on client websites one at a time, tracking each one in whatever is convenient — a notes app for credentials, a spreadsheet for invoices, email threads for support, a calendar reminder for monthly maintenance. It works at three clients. It starts fraying at ten. By the time you hit twenty or thirty websites under active management, the system is a liability.
The specific failure modes I kept running into: a client asks whether their site was backed up last week — I have to dig through server logs to answer. A staff member needs the cPanel password for a site — they message me, I open a notes file, paste it in a DM. That password just left the only controlled location it was stored in. A client raises an issue on a Friday at 4pm — it goes into an email thread that gets buried under ten other emails by Monday. A client asks what they're paying for this month — I send them an invoice I generated manually in a spreadsheet.
None of these are rare edge cases. They're the weekly operational reality of a web agency. The tools that existed for this work were either generic project management software that didn't understand the web agency context at all, or bloated agency platforms priced for fifty-person teams. I needed something purpose-built for how this work actually happens.
So I built Weprogs.
What Weprogs Is
Weprogs is a Laravel SaaS platform for web agencies and freelance developers who manage websites for multiple clients. It has three distinct panels built for three distinct roles:
The Customer Portal is where clients log in to see their websites, check maintenance status, view their subscription, raise support tickets, and request website additions or removals. Clients get visibility without needing to contact anyone. They can see whether their site is up, whether maintenance is scheduled, and what their support tickets are doing.
The Staff Panel is where the technical work happens. Staff members see their assigned tasks, handle maintenance activities (backup logging, plugin scanning, security scanning), log time against client work with a live timer, manage credentials from the secure vault, generate maintenance reports, and raise invoices. Everything is in one interface without context switching to five different tools.
The Admin Panel is where the agency owner manages everything: plans, users, subscriptions, billing via Stripe, and the overall agency operation. Plan configuration controls how many websites each customer subscription covers and what features they get access to.
The Credential Vault: The Feature I Was Most Careful Building
Storing client credentials is the most security-sensitive thing a web agency does. Every client site comes with a collection of access details: FTP and SFTP credentials, cPanel logins, WordPress admin accounts, database credentials, SSH keys, API keys. These are the keys to your clients' businesses. Handling them carelessly is not an option.
Weprogs supports eight credential types per website: FTP, SFTP, cPanel, WordPress, database, SSH, API key, and a catch-all other category. Each credential record stores a label, a free-text notes field, and a JSON fields object containing the actual sensitive data (host, port, username, password, and type-specific fields).
Envelope Encryption
All three text fields — label, fields, and notes — are individually encrypted before they hit the database. But encrypting everything with the same application key creates a problem: if you ever need to rotate the key, you have to decrypt and re-encrypt every single record in one operation. That's a maintenance nightmare.
Weprogs uses envelope encryption instead. Each credential record is encrypted with its own per-record data encryption key (DEK). The DEK itself is then encrypted with the application key and stored alongside the ciphertext in an encrypted_dekcolumn. When you need to read a credential, the application unwraps the DEK with the app key, then uses the DEK to decrypt the record. If the app key ever rotates, you only need to re-encrypt the DEKs — not the underlying ciphertexts. It's the same pattern cloud providers use for key management, applied at the application layer.
Audit Logging Every Access
Encryption protects credentials at rest. But it doesn't tell you who accessed what and when. Weprogs logs every credential interaction to a separate credential_access_logs table: the credential ID, the staff member who performed the action, the action type (view, create, update, or delete), the IP address, the user agent, and a metadata JSON field for additional context like which fields were modified.
This creates a full audit trail without requiring manual logging. If a credential ever appears in the wrong place, you have a complete record of every person who revealed it, from which device, at what time. It turns a sensitive vault into an accountable one.
The Monitor Agent: HMAC-Verified Uptime Tracking
Clients want to know their website is running. Agencies want to know before the client does when something is wrong. The Monitor Agent is the component that makes both possible.
The Monitor Agent is an API client that runs on each managed website and sends regular heartbeat events back to the Weprogs platform. Each website in the system has an agent secret — a unique key generated when the site is registered. Every request the agent sends is signed with HMAC using this secret, and the Weprogs API verifies the signature before processing the event.
HMAC is the right authentication mechanism here for a specific reason: it's stateless and deterministic. There are no tokens to rotate, no OAuth flows to maintain, no expiry to manage. The agent signs with its secret, the server verifies with the same secret, and that's it. For a machine-to-machine heartbeat running on potentially dozens of websites, this is dramatically simpler to operate than any token-based scheme.
When a heartbeat arrives, Weprogs updates the website's last_checked_at timestamp and maintenance_status. If a website goes silent — no heartbeat for longer than expected — the status flips to indicate a problem. The agent can also send structured event payloads for specific incidents: downtime, error spikes, or custom events the site owner defines. All of this feeds into the website's status view in both the staff panel and the customer portal.
Maintenance Automation
Maintenance work on client websites tends to fall into a predictable rhythm: you back up the site, you check whether plugins or extensions are outdated, you run a security scan to catch known vulnerabilities. Doing this manually for twenty websites means twenty separate tasks, twenty separate sets of notes, and twenty opportunities for something to slip through.
Weprogs automates the logging layer for three maintenance activities: backup runs, plugin scans, and security scans. Each run produces a log record — BackupLog, PluginScanLog, SecurityScanLog — that captures the outcome, the timestamp, and any relevant details. These logs feed into structured maintenance reports that can be shared with the client directly from their portal.
The result is that maintenance stops being reactive and invisible. Clients can see that their site was backed up on Tuesday and that the plugin scan found two updates that were applied on Wednesday. They don't have to ask. The agency doesn't have to write a monthly update email. The record is already there.
Time Tracking With a Live Timer
Most time tracking in agencies happens retrospectively: at the end of the day, or when it's time to invoice, someone tries to remember how long things took. That reconstruction is almost always inaccurate, and almost always conservative — people undercount the time they spent.
Weprogs includes a live timer in the staff panel. When a staff member starts work on a task, they start the timer. They can pause it and resume it. When the work is done, they stop it. The TimerSession table records the precise start and stop timestamps, which flow into TimeLog records attached to the client website and the staff member.
This changes the dynamic around invoicing. Time tracked by a running timer is objective — there's nothing to reconstruct. It also changes how the team estimates future work, because they have historical data on how long similar tasks actually took rather than how long they felt.
The Support Ticket System
Client communication about technical issues needs structure. An email thread is not structured — it's a chronological pile of replies with no status, no priority, no assignment, and no record of resolution.
Weprogs has a built-in ticket system scoped to each client website. Clients can open tickets from their portal; staff members can respond and close them from the staff panel. Tickets support message threads, staff assignments (TicketAssignment), and status tracking. Every ticket is linked to a specific website, so there's no ambiguity about which site an issue relates to.
Subscriptions, Plans, and Billing
Weprogs is itself a subscription product — agencies pay for access based on how many client websites they need to manage. Plans are configured with a maximum website count, a billing cycle (monthly, yearly, or lifetime), an optional trial period, and a JSON feature set. Stripe handles payments and webhook events.
The pricing page splits plans into single-website and multi-website tiers, so individual freelancers managing one or two sites and agencies managing twenty or more can both find a plan that fits without paying for capacity they don't need.
Technical Decisions Worth Explaining
Why Laravel
I've built multiple SaaS products on Laravel. It handles authentication, queues, Stripe webhooks, scheduled commands, and policy-based authorization without reaching for external packages for each concern. For a platform that needs clean role-based access control, background jobs for maintenance automation, and a REST API for the Monitor Agent alongside a traditional web UI — Laravel's included tooling covers the whole surface area.
Separating Web and API Routes
Weprogs has a strict split between routes/web.php (session-based Blade UI) and routes/api.php (JSON endpoints authenticated via Laravel Sanctum). The Monitor Agent and all programmatic access goes through the API routes. This separation matters because it keeps UI concerns and machine-to-machine concerns on different authentication stacks — session cookies are the wrong mechanism for an agent running on a remote server.
Two-Factor Authentication and Passkeys
A platform that holds encrypted credentials for dozens of client websites is a high-value target. Weprogs requires 2FA and supports passkeys for all user accounts. The authentication layer is not optional — anyone with access to the staff panel has access to the credential vault, which makes strong auth a baseline requirement, not a feature.
What I'd Tell Myself Before Starting
Role-based SaaS is one of those architectures where the early decisions calcify quickly. Getting the middleware and route structure right before writing any controllers — strict separation of customer, staff, and admin concerns at the routing layer, not enforced with conditionals inside shared controllers — saves a significant amount of refactoring later.
The credential vault was the feature I deliberated on longest, and that deliberation was worth it. Envelope encryption is more implementation work than a simple single-key encryption scheme, but the operational benefit (decoupled key rotation) is real. The audit logging felt like over-engineering at first. It's now the feature I'm most glad I didn't skip — every security-sensitive system needs a record of who touched what.
The Monitor Agent is the component that surprised me the most. It started as a simple uptime check and became the connective tissue between the platform and the actual websites being managed. HMAC is the right authentication choice for this use case — I tried to overcomplicate it early on with token-based auth and then went back to the simpler, more robust approach.
Weprogs is the platform I use to run my own agency. That constraint — it has to work for me, daily — is the most effective quality gate I've found for any product.