PEID: Founding and Architecting a Digital Pet Identity Platform
From a Headless Laravel API to a Symfony Rewrite With WhatsApp Delivery and an AI Pilot
A founder's engineering case study on PEID, a digital pet identity product: a headless Laravel 8 API with document generation, a 2023 Symfony 6 rewrite, WhatsApp delivery through UltraMsg, an OpenAI pilot and GitHub Actions deployment.
Executive Summary
In Peru, every person has a DNI, a national identity document. PEID gave pets one too.
Owners registered their pet and their own details and received a free virtual ID card. Revenue came from what people wanted next: a high-resolution version of the card and paid virtual certificates for moments owners care about, such as a first vaccine or a first pet.
I founded PEID and was responsible for its architecture through two generations. In 2021 I designed a headless Laravel API and led the developer who wrote most of it. In 2023 I rewrote the backend myself in Symfony, added WhatsApp delivery of the ID and certificates, and piloted an AI feature that let a pet “talk” to its owner.
The Product
| Element | How it worked |
|---|---|
| Pet ID (“DNI de mascotas”) | Free virtual ID card with front, back and a QR code |
| Owner account | One owner could register several pets |
| Paid upgrades | High-resolution ID image and virtual certificates (“Certipeids”) |
| Physical products | Printed cards and certificates at first, later dropped |
| Markets | Peru first, then other Latin American countries |
The physical products are a good example of a lesson learned early. Selling printed cards and certificates worked, but the logistics of producing and shipping them were too complex for a small team. Moving fully to digital products made the business simpler and the engineering cleaner: everything PEID sold could be generated, delivered and re-delivered by software.
Architecture Overview
| v1 (March – November 2021) | v2 (April – May 2023) | |
|---|---|---|
| Backend | Headless Laravel 8 API, PHP 7.3/8, MySQL | Symfony 6.2, Doctrine ORM and migrations, PHP 8.1 |
| Front end | Nuxt 2, separate app | Next.js 13 with TypeScript |
| Documents | PDF and image generation (dompdf, wkhtmltopdf/Snappy, Intervention Image/Imagick), QR codes, Excel export | Carried forward |
| Delivery | Downloads | Downloads plus WhatsApp through the UltraMsg API |
| AI | None | Internal OpenAI “talking pet” pilot |
| Deployment | DigitalOcean | GitHub Actions over SSH |
| Who wrote it | A developer I employed, with my architecture, proofs of concept and reviews | Me |
Engineering Approach Note
AN-001 — A Headless API From Day One
- Decision
- Laravel 8 as an API only, with a separate Nuxt front end
- Security
- API-key middleware and CORS rules for the front end
Context
The core of PEID was not a set of pages. It was generating documents: ID fronts and backs, QR codes, certificates as PDFs and images, downloads and exports. Several clients would need the same capabilities.
The Approach
Build the backend as a headless API with endpoints to create pet IDs and certificates and to serve the generated images, QR codes and downloads, protected by an API-key middleware. The front end became just one consumer of that API.
Tradeoffs
Headless means two applications to deploy instead of one. It paid off when the front end was replaced in 2023 and when WhatsApp became a new delivery channel for the same documents.
Engineering Approach Note
AN-002 — Leading the Build Instead of Typing It
- My role in v1
- Architecture, library choices, critical proofs of concept, hardest parts, code review
- Team
- Two developers I employed over time
Context
Before I adopt a framework for real work, I always experiment with it first. For v1 I needed to move fast with a small team, and I needed the team to keep moving without waiting on me.
The Approach
I designed the architecture, chose the libraries, built quick proofs of concept for the risky parts and wrote the hardest pieces. The developer then implemented most of the remaining code, while I reviewed it and held the line on practices: migrations, seeders and coding standards.
Tradeoffs
The commit history shows that division clearly, with most v1 commits from the developer. That was the point: the architecture and standards were mine, and the team could execute without waiting on me.
The 2023 Rewrite
Engineering Approach Note
AN-003 — Rewriting the Backend in Symfony, With Deployment Automated
- Stack
- Symfony 6.2, Doctrine ORM and migrations, PHP 8.1; Next.js 13 and TypeScript
- Deployment
- GitHub Actions: on push to main, SSH, pull,
composer install, Doctrine migrations
Context
By 2023 the product had a clearer shape, and I wanted a backend that matched it, plus a release process that did not depend on someone logging into a server.
The Approach
I wrote the new backend myself in Symfony with Doctrine, contributed to the new Next.js front end alongside another developer, and set up continuous deployment with GitHub Actions so every merge to main shipped with its database migrations applied.
Tradeoffs
A rewrite is always a risk for a small product. Doing it in a framework built around explicit services and migrations, with deployment automated from the start, kept that risk contained.
Engineering Approach Note
AN-004 — WhatsApp Delivery and a Talking-Pet AI Pilot
- Integration
- UltraMsg API for WhatsApp messaging
- AI
- OpenAI API, internal pilot only
Context
Generating a pet ID is only half the job. It also has to reach the owner somewhere they will see it, and the first contact is the best moment to start the next sale.
The Approach
I integrated WhatsApp through the UltraMsg API so the backend could deliver the pet ID and certificates there and run an automated first interaction designed to bring owners back for another purchase. In 2023, early in the current wave of AI products, I also built an internal pilot that used the OpenAI API to let a registered pet "talk" with its owner over WhatsApp.
Tradeoffs
UltraMsg connects a regular WhatsApp account rather than going through the official WhatsApp Business API, which made it fast to integrate for a small product. The talking pet stayed an internal pilot and was never released to customers.
Why I Paused It
PEID’s last activity was in May 2023. I paused it because it was not producing enough return compared with other work I had at the time, and I have not resumed it.
That is a normal end for a startup experiment, and it is worth saying plainly. The engineering held up: the API generated the documents, the rewrite shipped, and deployment was automated. The business case is what did not justify more of my time.
Lessons Learned
Model the product around what the software can deliver. Dropping physical products made PEID both simpler to run and simpler to build.
Headless pays off when channels change. The same document APIs served a new front end and a new WhatsApp channel.
Delegate implementation, keep the architecture. Proofs of concept, standards and reviews let a small team move without the founder writing every line.
Meet users where they already are. Delivering through WhatsApp turned a generated document into a conversation.
Approach Notes Summary
| Note | Topic | Nature |
|---|---|---|
| AN-001 | A headless API from day one | Implemented (v1) |
| AN-002 | Leading the build instead of typing it | v1 team practice |
| AN-003 | Symfony rewrite with automated deployment | Implemented by me (v2) |
| AN-004 | WhatsApp delivery and a talking-pet AI pilot | Implemented; AI as internal pilot |
Final Thoughts
PEID is the project where I held every role at once: founder, architect, reviewer and, in its second generation, the engineer writing the backend. It taught me to make technical decisions with the business in view, and to be honest when the business, not the code, is the part that needs to change.
Explore all Engineering Case Studies or read ECS-006: Building Georgia’s Statewide Analytics Dashboard Without an Application Server.
