Freelance Python developer in Paris: how I scope TJM missions

Freelance Python developer in Paris: how I scope TJM missions

Hiring a freelance Python developer in Paris often starts with a simple question: what is your TJM? (taux journalier moyen—the day rate). The number matters, but it is the wrong first question. A useful engagement starts with scope: outcomes, constraints, risks, and how progress will be measured. Without that, both sides argue about days instead of value.

I am Zeliang Yao, freelance Python developer operating through Hephaestus SAS in Paris. This article explains how I scope TJM missions in practice—so product owners, CTOs, and procurement partners know what a clear proposal looks like, and so other freelancers can reuse the structure.

TJM is a unit, not a product

A day rate is a billing unit. The product is a mission: a bounded outcome (or a clearly bounded capacity) delivered under agreed assumptions. Scoping turns vague requests—“we need a senior Python person for our AWS platform”—into something you can staff, estimate, and review.

Typical Paris-market missions for Python freelancers include:

• Greenfield APIs (FastAPI, Django) and service extraction
• Data / analytics pipelines on AWS or hybrid clouds
• Platform hardening: CI/CD, observability, performance
• Short rescue missions: stabilize production, reduce incident load
• Staff augmentation inside an existing squad with shared rituals

Each type needs a different scoping depth. Rescue work needs access and severity clarity on day one; greenfield work needs product boundaries and non-functional requirements.

The discovery conversation (before any TJM quote)

I treat the first call as discovery, not sales theater. Topics that must surface:

1. Business outcome — What changes for users or the business if this succeeds in 6–12 weeks?
2. Current system — Languages, clouds, critical paths, who on-calls
3. Constraints — Compliance, data residency, change windows, vendor lock-in
4. Team shape — Who reviews PRs, who owns product decisions, time zones
5. Definition of done — Demoable increments versus “be available N days/week”

If those answers are missing, any TJM is fiction. I would rather postpone a quote than invent certainty.

You can start that conversation via Calendly or contact.

Scoping formats that work

I usually propose one of three shapes:

1. Fixed-outcome slice (preferred when possible)

A thin vertical: e.g. “ingest → curated dataset → API for one dashboard use case,” with explicit out-of-scope items. Estimate in days with a confidence range; bill on TJM against that envelope, with a checkpoint to re-scope.

2. Capacity mission

N days per week for a quarter, embedded in the squad, priorities set in backlog refinement. Scope is the operating agreement (ceremonies, response expectations, what “urgent” means)—not a fake Gantt chart of unknown tickets.

3. Audit / architecture spike

Short, time-boxed review: architecture diagram, risk list, recommended backlog. Useful when stakeholders disagree on the problem. Output is a document and a workshop, not production code—unless explicitly extended.

Mixing all three without labeling them is how missions drift.

How I break work into estimable chunks

For Python / AWS-style delivery, estimation improves when work is sliced by risk and learning, not only by features:

• Spike unknowns (auth integration, venue protocol, data quality) early
• Separate “make it correct” from “make it fast”
• Put observability and deploy path in the first increments—not as polish
• Keep migration and dual-run plans visible when replacing a legacy path

Each chunk should have a demo or measurable exit: tests green in CI, endpoint live in staging, pipeline backfill completed for one partition, etc.

Assumptions, risks, and exclusions (write them down)

A TJM proposal without assumptions is a trap. I list:

• Assumptions — e.g. staging access by week one; product owner available twice weekly; cloud accounts already exist
• Risks — e.g. undocumented upstream schemas; flaky third-party APIs; unclear ownership of prod deploys
• Exclusions — e.g. mobile apps, 24/7 on-call unless contracted, rewriting unrelated legacy modules

When an assumption breaks, we re-scope; we do not silently eat infinite days. That is fairness to the client’s budget and to the quality of the work.

Paris context: language, contracts, and rhythm

Working from Paris with French and international clients adds practicalities:

• Bilingual communication — technical artifacts often in English; stakeholder workshops in French when needed
• Company structure — invoicing via Hephaestus SAS; clear purchase orders and mission orders (bons de commande) where required
• Hybrid / remote — on-site workshops for kickoff or architecture alignment; remote execution for deep build work
• Market expectations — senior freelancers are hired for judgment and delivery, not for ticket velocity theater

TJM comparisons across profiles only make sense when seniority, autonomy, and domain fit are comparable. A lower day rate that needs constant steering is more expensive than a higher rate that unblocks the team.

What “senior Python” means in a scope document

I avoid buzzword stuffing. In proposals, seniority shows up as:

• Ability to propose architecture options with trade-offs (not only implement a prescribed ticket)
• Comfort with production concerns: idempotency, backfills, SLOs, security basics
• Clear written communication: ADRs, runbooks, PR descriptions
• Knowing when not to introduce a new technology

If your mission needs a pair of hands inside a fully specified backlog, say so—the scoping and the TJM profile differ from “lead the redesign of our trading API on EKS.”

A simple scoping template you can reuse

1. Context (5–10 lines)
2. Goals and non-goals
3. Deliverables / increments
4. Roles (client / freelance)
5. Plan (phases, checkpoints)
6. Commercials (TJM, estimated days or capacity, expenses, notice period)
7. Assumptions, risks, exclusions
8. Next step (kickoff date, access checklist)

Keep it short enough that a busy CTO will read it. Long proposals that hide weak scope help no one.

Red flags on either side

Client-side: no owner for decisions; “we will know the requirements once you start”; production access promised “later”; success defined only as “help the team.”

Freelancer-side: refusing to write non-goals; estimating without seeing the repo or architecture; committing to fixed price on undefined scope; disappearing from async updates.

Healthy TJM missions are boring in the best way: regular demos, visible backlog, honest forecasts.

How engagement usually starts with Hephaestus

1. 30-minute intro — fit, timing, rough problem shape
2. Optional paid discovery / audit if the system is large or opaque
3. Written mission proposal with TJM and envelope
4. Kickoff with access checklist and first increment

Domains I know well from architecture-level work include portfolio analytics-style platforms, real-time APIs, and privacy-aware product engineering—always discussed at a level appropriate to confidentiality agreements.

Closing

Scoping is the craft behind a TJM. Paris has no shortage of Python freelancers; what clients remember is whether the mission stayed honest as reality changed. If you need a freelance Python developer who treats day rate as a billing unit and outcomes as the product, let us scope the work properly before we argue about the number.

---

Ready to scope a mission? Book 30 minutes on Calendly or use hephaestus.fr/contact. Hephaestus SAS — Zeliang Yao, freelance Python developer in Paris.