Frequently asked questions

It depends on scope. A security audit is not priced like a product build. Work can be billed hourly or as a fixed project once the scope is clear. Currency is US dollars (USD).

In USD. Hourly or fixed project, as agreed. Deposit and payment milestones are set when scope is locked; there is no public fixed rate without a brief.

It depends on complexity, the access you provide, and the kind of work (audit, incident response, or build). Small scopes close faster; larger ones ship in milestones.

We re-quote. Extra hours or a project addendum; scope creep is not absorbed silently. Better to say it early than stretch the same price.

A serious message with the problem, the stack, and the outcome you want. We agree scope, billing (hourly or project), and a work window. I reply after Shabbat.

While observing Shabbat, the craft rests. Profiles can be read; mail is not opened until Motzaei Shabbat. After that, I reply in earnest.

Spanish and English. Based in Santa Cruz de la Sierra, Bolivia; when I give Shabbat or other cutoffs, I use Argentina time (as on the site note).

Yes. Work is under agreement. Reports and findings go only to the authorized client. I do not publish real client cases or client data on the portfolio.

Yes. Based in Santa Cruz de la Sierra; the craft is remote unless the work requires presence.

Mercav.lat is the role and the product. Audit, incident-response, or build engagements are agreed separately: they are not Mercav customer support or a marketplace help channel.

Delivery closes the agreed scope; it does not include open-ended support. Ongoing maintenance or iterations can be hired hourly or as a separate package.

For teams and products that want a service that closes cleanly, a serious audit, or post-incident response with an actionable report. Not for offensive catalogs, cheats, or “break X for me” without a defensive mandate and clear authorization.

Surface review (APIs, authn/authz, flows), findings prioritized by risk, and a remediation-oriented report. I document the failure and the fix — not an exploitation playbook.

Agreed access (staging or scoped prod), a map of relevant endpoints or repos, and a technical contact. Without that, scope and timeline inflate.

I do not deliver offensive catalogs or recipes to break third-party systems. Grey-hat here means studying offense to design defense.

Timeline and entry vector, observed methods (patterns, not payloads), endpoints involved, data at risk, severity range, and a containment-and-close plan.

Containment and evidence first; reconstruction and report second. The window depends on severity and how much access the team gets.

Yes. Post-incident work reconstructs what happened, what was exposed, and what to harden so the same path stops being usable.

Backend and web logic (HTTP contracts, domain, auth, data) plus the UI needed for the product to close. One profile that designs the service and understands how it breaks.

Fixed project when scope is closed, or hourly when scope is evolving. Timeline follows complexity and client dependencies. Currency is USD.

Yes, when the scope is UI, accessibility, and consuming defined APIs. If the backend is weak, I say so early: UI does not hide broken authz.

TypeScript and React / Next when it fits. I adapt to the product stack when API contracts are clear.

Yes: APIs, authn/authz, domain, persistence, jobs, and clear layer boundaries. Also low-level C++20 when the problem calls for it.

Code and contracts that hold under load and abuse, with explicit auth and data limits. Endpoint and design notes when the project needs them.