Preguntas frecuentes

Depende del alcance. Una auditoría de seguridad no se cotiza igual que un desarrollo. Se puede cobrar por hora trabajada o por proyecto cerrado; lo acordamos cuando el alcance está claro. La moneda es dólares estadounidenses (USD).

En USD. Por hora o por proyecto, según lo acordado. Anticipo e hitos de pago se definen al cerrar el alcance; no hay tarifa pública fija sin brief.

Depende de la complejidad, del acceso que den al sistema, y del tipo de trabajo (auditoría, respuesta a incidente, o build). Un alcance chico cierra más rápido; uno grande se parte en hitos.

Se re-cotiza. Horas extra o un addendum de proyecto; no se absorbe el cambio en silencio. Mejor decirlo temprano que estirar el mismo precio.

Un mensaje serio con el problema, el stack, y el resultado que buscan. Acordamos alcance, modalidad (hora o proyecto), y ventana de trabajo. Respondo después de Shabat.

En observación de Shabat el oficio descansa. Los perfiles se pueden leer; el correo no se abre hasta Motzaei Shabat. Después de eso, respondo en serio.

Español e inglés. Base en Santa Cruz de la Sierra, Bolivia; cuando doy horarios de Shabat u otros cortes, uso referencia Argentina (como en la nota del sitio).

Sí. El trabajo se hace bajo acuerdo. El informe y los hallazgos van solo al cliente autorizado. No publico casos reales ni datos de clientes en el portfolio.

Sí. Santa Cruz de la Sierra; el oficio es remoto salvo que el trabajo exija presencia.

Mercav.lat es el cargo y el producto. Los encargos de auditoría, respuesta a incidentes o desarrollo se acuerdan aparte: no son atención al cliente de Mercav ni un canal de soporte del marketplace.

La entrega cierra el alcance acordado; no incluye soporte abierto indefinido. Si hace falta mantenimiento o iteraciones, se contrata por hora o por paquete aparte.

Para equipos y productos que quieren un servicio que cierre bien, una auditoría seria, o respuesta post-incidente con informe accionable. No para pedidos de catálogos ofensivos, cheats, ni “rompeme X” sin mandato defensivo y autorización clara.

Revisión de superficie (APIs, authn/authz, flujos), hallazgos priorizados por riesgo, e informe con remediación. Documento el fallo y el cierre — no un playbook de explotación.

Acceso acordado (staging o prod acotado), mapa de endpoints o repos relevantes, y un contacto técnico. Sin eso el alcance se infla y el plazo también.

No entrego catálogos ofensivos ni recetas para romper sistemas de terceros. Grey-hat aquí significa estudiar el ataque para diseñar la defensa.

Timeline y vector de entrada, métodos observados (patrones, no payloads), endpoints implicados, datos en riesgo, rango de severidad, y plan de contención y cierre.

Primero contención y evidencia; después reconstrucción e informe. La ventana depende de la gravedad y de cuánto acceso den al equipo.

Sí. Post-incidente se reconstruye qué pasó, qué se expuso, y qué endurecer para que el mismo camino no vuelva a ser usable.

Backend y lógica web (contratos HTTP, dominio, auth, datos) más la interfaz necesaria para que el producto cierre. Un solo perfil que diseña el servicio y entiende cómo se rompe.

Por proyecto cuando el alcance está cerrado, o por hora cuando el alcance evoluciona. El plazo sigue la complejidad y las dependencias del cliente. La moneda es USD.

Sí, cuando el alcance es UI, accesibilidad, y consumo de APIs ya definidas. Si el backend está flojo, lo digo temprano: la UI no tapa authz rota.

TypeScript y React / Next cuando encaja. Me adapto al stack del producto si el contrato de APIs es claro.

Sí: APIs, authn/authz, dominio, persistencia, jobs y límites claros entre capas. También C++20 de bajo nivel cuando el problema lo pide.

Código y contratos que aguantan carga y abuso, con límites de auth y datos explícitos. Documentación de endpoints y decisiones de diseño cuando el proyecto lo requiere.