DEV Community: Freelance Deal Desk

Cómo calcular el precio de un proyecto freelance sin improvisar

Freelance Deal Desk — Thu, 30 Jul 2026 16:26:57 +0000

Cotizar un proyecto freelance no consiste en multiplicar horas por tarifa. Ese cálculo es un punto de partida, pero deja fuera el tiempo no facturable, el riesgo, los cambios de alcance y las comisiones.

Una propuesta profesional necesita mostrar una cifra que puedas defender y un alcance que el cliente entienda.

La fórmula mínima

Empieza por convertir tu objetivo mensual en una tarifa operativa:

tarifa operativa = objetivo mensual / horas facturables reales

Las horas facturables no son las horas que trabajas. Son las que realmente puedes dedicar al cliente después de ventas, reuniones, administración, aprendizaje y descanso. Si trabajas 160 horas al mes pero sólo 80 son facturables, usar 160 para cotizar reduce tu tarifa a la mitad.

Después calcula el costo base:

costo base = tarifa operativa × horas estimadas

Y protege ese resultado:

precio recomendado = (costo base + contingencia) / (1 − margen)

La contingencia cubre incertidumbre técnica razonable. El margen cubre la responsabilidad, la comunicación y el valor de entregar un resultado que funciona. No es un número inflado: es la parte que hace sostenible el trabajo.

Un ejemplo sencillo

Supón un objetivo mensual de $3,000 USD y 80 horas facturables. Tu tarifa operativa es $37.50/hora. Para una estimación de 18 horas:

Costo base: $675
Contingencia del 10%: $67.50
Con margen del 35%: $1,142.31

El resultado no obliga a cobrar exactamente esa cantidad. Sirve para decidir con claridad si el proyecto debe tener un precio fijo, dividirse en fases o requerir una conversación de alcance antes de dar un número final.

Antes de enviar una cifra, responde esto

¿Qué resultado concreto espera el cliente?
¿Qué queda fuera del trabajo?
¿Qué necesita entregar el cliente para empezar?
¿Cuántas rondas de revisión están incluidas?
¿Qué evento convierte el proyecto en “terminado”?

Si una respuesta no está clara, anótala como supuesto en la propuesta. Así un cambio deja de ser una discusión ambigua y pasa a ser una decisión comercial explícita.

La cotización es una herramienta de ventas

Una propuesta que sólo muestra un precio fuerza al cliente a adivinar el resto. Una buena propuesta conecta contexto, solución, entregables, calendario, inversión y próximos pasos. Eso reduce fricción y te permite decir “sí, con este alcance” en vez de negociar desde el miedo.

Preparé un kit comercial editable para freelancers de software con cuestionario de descubrimiento, plantilla de propuesta, calculadora de proyectos en Excel y mensajes de seguimiento. Está disponible en Freelance Deal Desk.

Stripe webhooks need a state machine, not just a switch statement

Freelance Deal Desk — Thu, 30 Jul 2026 05:38:05 +0000

Most Stripe Checkout examples stop at this:

switch (event.type) {
  case "payment_intent.succeeded":
    // mark paid
}

That is a useful beginning, but it is not yet a payment workflow. A real booking flow also has a calendar slot, a database record, retries, late events, and sometimes a human approval step. Treating each webhook as an isolated callback leaves gaps where a paid customer can lose a slot—or where a failed payment leaves a slot unavailable forever.

Here is the smaller model I use before wiring an application to live vendor APIs.

Make the booking state explicit

Record three separate facts:

payment_status: awaiting_payment, paid, or failed
slot_status: held, confirmed, or released
approval_status: not_required, pending_approval, approved, denied, countered, or expired

Those states are deliberately independent. A booking can be paid while its calendar confirmation is retrying. A low-value booking can be held while an operator decides whether to accept it. And a failure must release a held slot without touching a slot that has already been confirmed.

Idempotency belongs at the event boundary

Stripe retries webhooks. Your endpoint must therefore persist the event ID before it performs side effects. A second delivery should return success without charging, confirming, or releasing anything again.

if (seenStripeEvents.has(event.id)) return { duplicate: true };
seenStripeEvents.add(event.id);

if (event.type === "payment_intent.succeeded") {
  await confirmSlot(booking.calSlotId, booking.slotKey);
  await writeBilledBooking(booking, event.data.object.id);
}

In production, seenStripeEvents should be a table with a unique event ID, written in the same transaction that changes the booking state. An in-memory set only makes the example easy to read.

Use one stable key for calendar side effects

A booking ID makes a good idempotency key for the calendar provider:

booking:<booking-id>

Pass that same key when holding, confirming, and releasing a slot. If a network request times out after the provider completed its work, retrying with the same key is safe. This is much better than trying to infer state from a transient API error.

Never trust a webhook without its raw-body signature check

The signature must be computed over the exact raw request body and rejected outside a short replay window. Do this before JSON parsing when the framework requires it. Constant-time comparison also avoids turning a signature endpoint into an oracle.

const expected = createHmac("sha256", secret)
  .update(`${timestamp}.${rawBody}`)
  .digest("hex");

const valid = actual.length === expected.length &&
  timingSafeEqual(Buffer.from(actual, "hex"), Buffer.from(expected, "hex"));

Test the recovery paths first

The happy path is easy to picture. The useful tests are the awkward ones:

payment_intent.succeeded delivered twice confirms the slot once.
payment_intent.payment_failed releases a held slot.
A manual denial releases its hold.
An expired approval releases its hold.
A successful payment cannot bypass a required approval.
Altered or stale webhook signatures are rejected.

Writing these tests before connecting Stripe or a calendar API forces the product decision into code: every hold has a release path, every external event is repeat-safe, and billed records have an immutable payment ID.

For a separate walkthrough of promotion codes in Stripe Checkout, see this test-first guide.

Stripe Checkout promotion codes: a safe test-first rollout

Freelance Deal Desk — Thu, 30 Jul 2026 05:23:28 +0000

Stripe-hosted Checkout is designed to keep payment flows simple, but promotions deserve the same care as any other billing change. The safest rollout is small, reversible, and tested before it touches a live subscription.

1. Identify the Checkout path first

Start by confirming whether the hosted page is created through the Checkout Sessions API or a Payment Link. The two paths expose promotion settings differently, so this one question prevents needless changes to an otherwise working integration.

For a Checkout Session created on your server, enable the customer-facing field with allow_promotion_codes: true. For Payment Links, Stripe supports promotion codes in the Dashboard and through its Payment Links settings.

2. Separate the discount from the public code

A coupon defines the discount. A promotion code is the customer-facing code that can apply that discount. Give the promotion code a clear scope and an expiration or redemption limit when appropriate. That makes it easier to stop a campaign without rewriting your Checkout flow.

3. Test with separate test-mode objects

Use a test-mode product and price. Run a full checkout using the proposed promotion code, then confirm:

the discounted total is correct;
subscription behavior is still correct;
success and cancel URLs are unchanged;
your existing post-checkout handling still runs.

For many integrations, enabling a promotion field is a focused configuration change—not a reason to rework prices, webhooks, or billing logic.

4. Keep a rollback switch

Before production, decide who can disable the promotion code and where that is documented. A promotion should be easy to retire. Record the code, the linked coupon, its scope, and the test performed.

Production-ready implementation template

If you want a starting point that includes the Checkout creation route, customer-entered promotion codes, signed webhooks, idempotent fulfillment, and a test checklist, I made a production kit for exactly this workflow.

Stripe Checkout Promotion Codes — Production Kit (USD 29)

Launch note: use code LAUNCH10 at checkout for 10% off this kit.

This article is educational and is not financial, tax, or legal advice. Always test in Stripe Test mode before changing a live payment flow.

5 preguntas antes de cotizar un proyecto de software

Freelance Deal Desk — Thu, 30 Jul 2026 04:20:21 +0000

Una consulta que dice “¿cuánto cobras por hacer una web?” no es todavía un proyecto. Es una señal de que alguien tiene una necesidad, pero aún no ha convertido esa necesidad en alcance, prioridad ni inversión.

Responder con un número demasiado pronto suele crear uno de dos problemas: cobras por una versión imaginaria del trabajo, o pasas días persiguiendo detalles que debieron estar claros al principio.

Estas son las cinco preguntas que uso para convertir una conversación inicial en una propuesta que se pueda evaluar.

1. ¿Qué debería ser diferente cuando esto esté terminado?

No preguntes solamente qué páginas o funcionalidades quieren. Pregunta qué cambio esperan conseguir: más solicitudes, menos trabajo manual, una mejor demostración del producto, una experiencia de compra más simple.

La respuesta revela el resultado que realmente valoran. También te ayuda a distinguir entre una petición urgente y una mejora “algún día”.

2. ¿Qué está ocurriendo ahora y por qué no funciona?

Una solución tiene sentido sólo dentro de su contexto. Pide un ejemplo concreto del flujo actual: quién hace qué, qué tarda demasiado, dónde se pierden oportunidades y qué ya intentaron.

Esta pregunta reduce el riesgo de construir una función bonita que no resuelve el cuello de botella real.

3. ¿Quién decide y quién usará el resultado cada día?

El comprador, la persona que aprueba y el usuario final a menudo no son la misma persona. Saberlo cambia cómo presentas la propuesta, qué validaciones necesitas y cuánto tiempo debes reservar para revisiones.

Una frase útil es: “Además de nosotros dos, ¿quién necesita estar de acuerdo antes de empezar?”.

4. ¿Qué tiene que incluir esta primera versión y qué puede esperar?

Pide que separen el “imprescindible para lanzar” de las mejoras deseables. Después confirma por escrito la primera lista.

No se trata de recortar valor: se trata de proteger la fecha, el presupuesto y la calidad. Un alcance pequeño y claro es mucho más convincente que una lista interminable de posibilidades.

5. ¿Qué fecha, presupuesto o restricción no podemos ignorar?

La fecha puede venir de una campaña, un evento, una renovación o una operación interna. El presupuesto puede tener margen, pero rara vez es infinito. Preguntar de forma directa permite proponer alternativas reales: una fase inicial, menos integraciones o un calendario distinto.

Evitar la conversación de presupuesto no la elimina; sólo la deja para el peor momento.

Convierte las respuestas en una propuesta de una página

Después de la llamada, resume lo escuchado en este orden:

El problema y el resultado esperado.
El alcance de la primera versión.
Qué no está incluido todavía.
La inversión, calendario y forma de trabajo.
El siguiente paso concreto para empezar.

Cuando el cliente puede reconocer su propia situación en las primeras líneas de una propuesta, la conversación deja de ser una comparación de precios y se convierte en una decisión de negocio.

Durante los próximos 7 días, obtén Freelance Deal Desk por $20 USD con el código START20. Incluye cuestionario de descubrimiento, plantilla de propuesta, calculadora de proyectos y mensajes de seguimiento para freelancers que quieren vender con más claridad.