You will get data pipeline monitoring with alerts when a job runs but moves no data
Rising Talent
Project details
A crashed job gets noticed. The dangerous one finishes, reports success, and moves nothing - and the numbers downstream just quietly stop being true.
I put a small monitor beside your pipelines and check three things every run: did the job actually land when it should have, did it move a normal number of rows, and did the tables it feeds get any newer. Thresholds come from your own history, not from a guess, so a slow Tuesday does not page you.
On my own test suite I staged eight failures of exactly this kind - a skipped run, a load that moved 3% of normal, a table frozen for days - and all eight were caught, while healthy runs raised nothing. I will do the same with yours before handover: stage the failure, show you the alert.
Nothing runs inside your pipeline, so nothing new can break it. Read-only access is enough. Postgres, Supabase, BigQuery and Google Sheets all work, and you keep the code plus a short written guide.
How I work: written messages and screen recordings with notes on screen. I do not take live calls - a health condition rules out voice - and clients tend to prefer having it in writing anyway. Send your job list or schedule - fit confirmed in 24h.
I put a small monitor beside your pipelines and check three things every run: did the job actually land when it should have, did it move a normal number of rows, and did the tables it feeds get any newer. Thresholds come from your own history, not from a guess, so a slow Tuesday does not page you.
On my own test suite I staged eight failures of exactly this kind - a skipped run, a load that moved 3% of normal, a table frozen for days - and all eight were caught, while healthy runs raised nothing. I will do the same with yours before handover: stage the failure, show you the alert.
Nothing runs inside your pipeline, so nothing new can break it. Read-only access is enough. Postgres, Supabase, BigQuery and Google Sheets all work, and you keep the code plus a short written guide.
How I work: written messages and screen recordings with notes on screen. I do not take live calls - a health condition rules out voice - and clients tend to prefer having it in writing anyway. Send your job list or schedule - fit confirmed in 24h.
Database Type
MySQL, PostgreSQLWhat's included
| Service Tiers |
Starter
$99
|
Standard
$199
|
Advanced
$349
|
|---|---|---|---|
| Delivery Time | 3 days | 5 days | 7 days |
Number of Revisions | 1 | 2 | 3 |
Source Code |
Frequently asked questions
3 reviews
(3)
(0)
(0)
(0)
(0)
This project doesn't have any reviews.
NK
Natalija K.
Aug 20, 2026
Python / Playwright Developer – Financial Website Data Extraction PoC
Jigon did a very thorough and technically detailed job. I particularly appreciated his transparency about limitations and unexpected findings — he consistently documented issues rather than trying to hide or work around them. The final deliverables were comprehensive, and the technical handover was well structured and useful for continuing the work independently. The project turned out to be significantly more complex than initially expected, and Jigon put a lot of effort into investigating the technical challenges. Overall, I’m happy with the work delivered and appreciate his professionalism and attention to detail.
TF
Tyler F.
Aug 10, 2026
Start for supabase move
Another project completed with Jigon, he is very easy to work with and clear communication. Will continue to work with him and recommend for everyone
TF
Tyler F.
Jul 28, 2026
WNBA Player Prop Model
Highly recommend and will continue doing work with Jigon! Impressed with the details and knowledge he brought. Exceeded expectations!
About Jigon
Data & AI systems you can verify | Evidence, gates, and reports
100%
Job Success
Gyeonggi-do, South Korea - 8:51 am local time
How I work with clients. Fixed price by scope, agreed before anything starts and split into milestones with one named deliverable each, so the cost is settled before the work is done rather than counted after it. Fully async, in writing - no live calls. Handover and tests ship with the work, so nothing depends on me still being around.
What I do:
• Data for automated and physical systems - sensor logs, run telemetry and event streams treated like any other production data: scheduled ingestion, schema validation, drift detection, and failure logging that surfaces a bad run instead of averaging it away. If a machine produced the number, your pipeline should be able to tell you when that number stopped meaning what it used to
• Web scraping and data extraction - messy sources into clean, validated Excel/CSV/JSON, with the rows that need a human flagged instead of silently dropped
• Korean-language data work - native Korean, handled as engineering rather than translation: OCR quality control on Korean documents (spacing around 조사 and 의존명사, character confusion, reading order in tables and vertical text), 자모 NFC/NFD normalization before it quietly breaks your deduplication and accuracy metrics, and structured extraction from Korean sites, forms and records
• Python ETL and pipelines (Postgres/Supabase) - scheduled runs, idempotent loads, and failure logging that actually surfaces failures instead of hiding them
• Document and LLM work - invoice and statement extraction with reconciliation checks, RAG question answering that cites its source and refuses when it can't, plus guardrails and evaluation harnesses that turn "looks fine" into a number
What you get: every deliverable ships with the evidence behind it - what was checked, what failed, and what a human should review. If something can't be done honestly at the scope or price you have in mind, I will say so before we start rather than quietly cut corners.
Ongoing work: most of what I build runs on a schedule, which means it needs someone watching it after launch. I take retainers for monitoring, drift checks and scheduled refreshes on pipelines I built or inherited. Clients usually start with one bounded piece and continue from there - my current client is on his third contract with me.
How I work: fully async, in writing. I use modern AI tools to move faster on drafts and boilerplate, and I personally review, test, and stand behind every deliverable. You get speed and a human who owns the result.
Recent work: a WNBA player prop model (scraper to prediction to live board) and a Supabase database migration for a sports analytics site.
Proof before you hire: my case studies are public, and each one ships with its full source code and the measured numbers attached - what was checked, what it caught, what it missed. Several were built to fail on purpose: I plant known defects in the input, then publish whether the checks caught all of them and how many false alarms they raised, because a checker that never cries wolf and a checker that cries constantly are both useless. Open any project in the portfolio below and the code and the results are linked from it.
Most recent, all public and reproducible: warehouse-quality-gate is a dbt contract on DuckDB - the sabotaged batch loads with zero errors and reports $4,905,051 of revenue instead of $395,751, and the contract fails 12 of 15 tests so the mart is never built. dag-guard reviews Airflow DAGs statically with ast, no Airflow install and no imports - 12 of 12 planted defects caught, including a catchup setting that queues 90,816 backfill runs the moment it deploys. metrics-contract prices definition drift between dashboards instead of just naming it - net revenue 697,691 by the contract, 755,388 on the dashboard, +8.3%. fhir-quality-gate checks FHIR R4 bundles that are already structurally valid - E119 written instead of E11.9 silently drops 3 patients out of a 46-patient quality measure, and nothing errors.
Steps for completing your project
After purchasing the project, send requirements so Jigon can start the project.
Delivery time starts when Jigon receives requirements from you.
Jigon works on your project following the steps below.
Revisions may occur after the delivery date.
Learn what a normal day looks like
I look at your recent run history and write down the normal shape: when each job lands, how many rows it usually moves, which tables should change. You confirm the bands before I build.
Build the checks and prove they catch a silent failure
Heartbeat, volume and freshness checks go in. Then I stage the failures that matter - a job that skips, a run that moves nothing, a table that stops updating - and show you each alert firing.