Human Resources Mexico

Introduction

The hardest part of building the HRM (Human Resources Mexico) platform wasn’t the code. It was getting 16 years of operational knowledge out of one person’s head.

Human Resources Mexico has been running for 16 years, a PEO (Professional Employer Organization) company that manages external employees for businesses operating in Mexico. In that time, its leader built a system that works: clear processes, precise legal documentation, and complex data relationships between companies, contacts, proposals, contracts, and employees.

‍

‍

HRM’s leader said it in the early sessions with our team. Not as an alarm, as a clear diagnosis from someone who has watched his industry operate for nearly two decades.

When he came to LowCode Agency, he didn’t come with a brief. He came with a Glide app he had built himself in roughly 45 hours, learning from YouTube videos, just to be able to show someone what he needed.

‍

‍

That said everything. The knowledge was there. What didn’t exist was a way to transfer it.

‍

The problem no brief could have captured

HRM runs five operational modules: client engagement, employee engagement, vendor engagement, government engagement and internal engagement. Each depends on the one before it. And all of them depend on a data architecture its leader had developed over years of real operations, with its own logic, specific terminology, and relationships between entities that have no equivalent in any generic system.

The risk wasn’t technical. It was understanding. Building the wrong system with the right technology would have been just as costly as building nothing at all.

What nobody had named yet: the real bottleneck at HRM wasn’t a lack of technology. It was that operational knowledge had never been structured in a way anyone else could execute reliably. Every process depended on its leaders being available to interpret, correct, and complete what the systems couldn’t handle on their own. With 20 internal users and five operational modules to build, that wasn’t sustainable.

‍

One week to translate 16 years of operations into architecture

Before designing a single screen or coding, our product engineering team ran a short, intensive sprint with the HRM team. One daily call, one hour each. Five sessions. One goal: eliminate all ambiguity and turn HRM operational knowledge into a data model and set of workflows precise enough to build on.

The process started with the process flow, mapping every operation from end to end, identifying who does what, when, and how. That map became the foundation for everything that followed: the user flows, the data structure, and eventually the detailed data sheet that documented every field, permission, and notification in the system. Nothing was left to interpretation. If it wasn’t in the documentation, it wouldn’t be built.

The starting point was a distinction our team locked in during the first session: everything in the system is built on two base entities, companies and contacts. Not clients, not employees, not prospects. Companies and contacts. Because a company can be a prospect, an active client, a former client, or a service provider. And a contact can be an internal employee, an external employee, a candidate to hire, or a representative from a client company.

Without that distinction established from the start, every future module would have inherited structural ambiguity that becomes technically impossible to fix later.

From there, we mapped the complete Client Engagement flow: from a prospect filling out a web form, through proposal generation, acceptance, client data collection, CSA (Client Service Agreement) and Exhibit A generation, digital signature, and through to the offer letter for the employee. Every step is documented with its actors, input data, approval conditions, notifications, and parent-child relationships in the database.

One detail that shaped architectural decisions: they didn’t want full automation. HRM sells precisely the opposite, human contact, manual review, real experts responding to every case. The system had to do the heavy lifting without eliminating the human checkpoints that are part of the product. A concrete example of that balance: the expiration date on every proposal is calculated automatically, same day, one month forward, but the proposal date is always chosen manually by whoever generates it, because sometimes it’s prepared before it’s sent.

A small detail. But exactly the kind of logic that only surfaces when you know the operation well enough to ask the right questions. They said it best at the close of the final session:

That’s the job. Not moving fast. Moving correctly.

‍

‍

What we built

Module 1 centralizes the complete client engagement cycle in a single platform, replacing scattered spreadsheets and Adobe Sign for document workflows.

The core of the system is the companies-contacts relationship. From there, every proposal, every CSA, every Exhibit A, and every offer letter exists as a child relationship tied to the correct entity, not to the process, but to the company or contact it permanently belongs to. That means at any point HRM leaders can open a company record and see the complete history: proposals, contracts, signed documents, associated employees.

Document generation runs on a deliberate review workflow. When a client completes the unified CSA and Exhibit A form, the information doesn’t go directly into the contract. It arrives in the system, a team member receives a notification, reviews and edits if there are errors, adds the information only HRM can provide, and then generates the document. The generate button is a checkpoint, not an automatic trigger.

Proposals have their own data logic. A prospect can have only one active proposal, but that proposal can contain multiple employee groups, each representing a hiring profile with specific salary and benefits conditions. If two engineers have the same salary, they go in the same group. If one earns differently, a separate group is created. That distinction matters because it’s the foundation of the contract calculations.

The system also maintains version history on documents that rarely change but matter significantly when they do, like CSAs that get regenerated when a client updates conditions or adds employees. With 16 years of operations, they knew exactly when that happens: around 5% of cases, according to them. Infrequent, but critical to have the record when it does.

‍

‍

Technical decisions that support the operation

We chose Glide for its ability to handle complex data relationships with an interface that operational teams can adopt without friction. The data model they had built in his prototype, companies, contacts, proposals, employee groups, CSAs, choices, served as a direct blueprint for the architecture of the new system. We didn’t migrate it. We reinterpreted it with the right structure from scratch.

The decision to build from scratch rather than on top of their prototype was deliberate. The prototype did its job perfectly: communicate. But a production app serving 20 internal users, generating legal documents in two languages, and scaling to five modules requires a database designed for that from the start, not adapted from a proof of concept.

During the final sessions, our product engineering team identified an additional opportunity: HRM manages a large volume of documents, offer letters, contracts, agreements, and finding specific information across those files was a manual, time-consuming process. We proposed building a separate AI layer powered by Pinecone that would allow any team member to upload a document and ask questions about its content in plain language. Instead of searching manually through files, the system returns a precise answer pulled directly from the document. We demonstrated it live using HRM’s own offer letters. The direction was confirmed on the spot.

Document signing moves out of Adobe Sign and into a native Glide workflow. When a document is ready, the system sends it for signature, tracks its status, notifies the relevant team member when it’s signed, and stores the signed version as a child of the correct company or contact record. One system, one place, full history.

User permissions mirror exactly how the team operates internally: all users have full access to every function, except deleting records and managing users, privileges reserved for the two super admins. The reason is operational: HRM cross-trains across departments. Restricting by role makes no sense when any team member may need to see or execute any process at any given moment.

‍

What changed after launch

Module 1 shipped. Module 2 refinement started immediately, with the same team. For a founder who built his own prototype just to make sure he was understood, continuing isn’t a formality, it’s a verdict.

In the nine months since launch, 57 proposals and 30 CSAs have moved through the platform, each one with a complete audit trail tied to the correct company or contact record. What used to require opening multiple cases, coordinating over email, and doing manual follow-up now happens in one place. The operations lead can see the status of every proposal, every CSA, and every document pending signature without asking anyone.

And the foundation is already built for what comes next. The companies-contacts architecture structured in eight weeks now supports every module that follows.

‍

‍

What this means for founders with complex operations

The HRM story doesn’t start with code. It starts with a week of precise questions.

He came in with 16 years of expertise, a working prototype, and enough clarity to know he needed someone who would understand the problem before solving it. That’s where our product engineering team took over.

At LowCode Agency, every project begins with a structured process our team runs before a single line of code is written. Our product engineers lead daily sessions with the client to map every operation, define every data relationship, and document every decision in detail. The output is a PRD (Product Requirements Document), a detailed blueprint that captures every decision before development starts. It’s how we make sure what gets built actually matches how the business works.

For founders running complex businesses, with multiple user roles, legal documentation workflows, and operational knowledge that lives in people rather than systems, speed of construction isn’t the priority. Clarity of what’s being built is.

If you have a business that already works well and need a system that reflects it precisely, that’s exactly the work we do.

Let’s talk.