Straight answers before the first meeting.

A 20-minute meeting about the process or processes you want to change, or a product idea: who does the work, how often, what it produces, where it breaks, and what happens when it is wrong. You do not need to prepare anything except, if possible, the person who actually does the work. It ends with one of three answers, in writing the next business day: worth building, worth a closer look first through a concise assessment, or not yet. If the answer is not yet, we tell you what would have to change first. There is no obligation and no follow-up pressure.

The RJMC team, led by the founder, Reynel Miralles. The people who run your diagnostic and write your scope are the ones who build the system and lead the handoff, so nothing is lost between the people who understood the problem and the people who solved it.

A small number, by design. Every build gets the team’s full attention from scoping to handoff, so a new one starts only when it can have it, and the scope states the start date. If we cannot start when you need us to, we say so before you sign.

A single process with clear rules typically has a working version on your real files within the first week and is handed over in two to three weeks. Several processes, or anything that has to connect to an ERP or a CRM, typically runs four to six weeks. The scope document states the timeline before you sign, tied to the dates files and access arrive.

Sample files, the real ones, not cleaned up. Access to the person who does the process today for two or three short sessions. A decision maker who can sign the scope. That is all.

Yes, and in larger companies we expect to. Before anything is installed, IT receives a written description of what runs where, what data it touches, and what access it needs. Where there is no IT team, the system is designed to run without one: in the browser, from a shared folder, or as a small tool that reads the exports you already produce.

We can, and we generally advise against it. One process taken to a working version teaches both sides how the other works, and the second one goes faster because of it. If two processes are tightly connected, they are scoped as one build.

Then you have been spared a project. You receive the reasoning in writing and, where one exists, a note on the simpler remedy: a template, a checklist, a change of sequence. Nothing further is expected of you.

Acceptance is measured against the criteria written into the scope before work starts, not against a general impression. When the build is delivered, you have a review period, stated in the agreement, to test it against those criteria and tell us in writing about anything that falls short. We correct it, and you review the corrected items again. If the review period ends with nothing reported, or the system goes into everyday use, the build counts as accepted.

Yes. We build internal tools and back-office applications, client and partner portals, integrations and data pipelines, reporting, and replacements for legacy tools and critical spreadsheets. A build can combine software and AI, and the scope says which parts are which.

It starts with the free diagnostic meeting. For a wider view, a concise assessment. We sit with the people who do the work, measure where the hours go, and write an AI roadmap: which processes are worth changing first, what to build, what to buy off the shelf, what to leave alone, and in what order, with the technology stack and the architecture for the first items and a defined scope for the first one. We also set up workplace AI for teams on approved tools, with a short usage policy. The roadmap is yours to act on with us or with anyone else.

Mainly Anthropic’s Claude, accessed through its commercial API. It reads long documents and PDFs directly, returns structured output in a fixed format and can cite the passage an answer came from. Its commercial terms exclude training on customer data. The model is chosen per task, kept in configuration so it can be changed later, and named in the scope with its provider. Where data must stay inside your own cloud account, Claude can run through Amazon Bedrock or Google Cloud in that account.

No number before the diagnostic, and no figure in a proposal unless it was measured in your own process. Published research shows what is within reach: in three randomized field experiments at Microsoft, Accenture and a Fortune 100 company, covering 4,867 developers, the ones given an AI assistant completed 26% more tasks (Cui, Demirer and co-authors, Management Science, 2026). Your scope states the baseline we measure before the build and the re-measurement 30 days after handoff, so the gain you see is yours, on your own files.

The ones that repeat on a cycle, follow rules a person could write down, and arrive as documents or exports: invoice intake, bank and card reconciliation, intercompany matching, the reporting pack, commission and allocation runs. Anything that is mostly judgment is a poor first candidate, and the diagnostic will say so.

No. It works around the systems you already run. Typically it reads what arrives, prepares entries or matches, and hands your ERP a file or an import in the format it already accepts. Nothing about your chart of accounts or your approval hierarchy has to change.

Every run leaves a record of what came in, what the system decided, and why. Items below a confidence threshold, or above an amount you set, go to a person for approval. Segregation of duties is kept: the system prepares, a person approves. The scope document lists the controls before anything is built.

It is designed to say so. Anything it cannot read cleanly, match with confidence, or classify under a known rule is flagged and routed to a person with the reason attached. It is built to be wrong loudly rather than quietly.

Only to the systems and providers named in the scope document. Where a language model is used, it is accessed through a commercial API whose terms exclude training on customer data, and the scope names the provider and its retention terms. Each run keeps an audit record of inputs, decisions and reasons, stored where you choose. Sensitive data stays in your environment unless you approve otherwise in writing.

Often, yes. Document reading, rules engines and reporting can run on infrastructure you control. Where a language model is needed and your cloud provider offers it, it can run through your own cloud account, so data stays under agreements you already have. If data cannot leave your environment at all, the diagnostic says so and we design around it or leave that part out.

Regulated data, such as health, card or consumer financial records, is in scope only when the obligations that apply are named in writing, along with hosting that meets them. The scope lists exactly which fields leave your systems. Where we cannot meet a requirement, we say so and leave that part out.

You own the code, configuration and documentation written for you, upon acceptance. Any reusable tooling we bring stays ours and is licensed to you permanently for use in your system. Open-source components keep their own licenses. Third-party services such as a model API or hosting are set up on your own accounts wherever possible, under their providers’ terms. Nothing we control can switch the system off. We keep the right to describe the work without naming you.

Two answers. First, the handoff includes walkthrough sessions on real cases, as set out in the scope, so your team can change the rules and diagnose a failure themselves, and the documentation is written for that reader. Second, an optional standing monthly arrangement covers monitoring, rule changes and model upgrades. It is proposed at handoff and never required.

Yes, and it is built so they can. Plain, well-known technology, rules kept in configuration rather than buried in code, and documentation that explains why decisions were made, not only how the system works.

Rules that are likely to change, such as thresholds, account mappings and approval limits, sit in a configuration a non-technical person can edit, and the walkthrough covers exactly that. A structural change is a new, short piece of work, scoped the same way.

Yes. Working sessions run over video, so location is rarely a constraint. We take on work across the United States and Latin America, and clients in South Florida can meet in person.

Yes. Diagnostics, scope documents, the system interface, documentation and the walkthrough can all be in Spanish.

A product asks you to change how you work to fit its assumptions. We build around the way your process actually runs, including the exceptions. When a product genuinely fits, the diagnostic will tell you to buy the product.

Advice and delivery come from the same person. A roadmap from us is one we are prepared to build, on your files and with your team, so nothing is lost between the recommendation and the result.