The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
SmashRank, my padel ranking app, is now in production on Google Play, out of closed testing.
By the numbers, straight from the repo:
→ 195 commits since the first one on 9 July
→ ~68 screens
→ 45 database tables
→ 133 migrations
The ratio I keep looking at: 133 migrations for 45 tables, roughly 3 per table.
The schema was never done on day one. Many migrations are product rules showing up in the data model:
→ 0016: admin dispute resolution
→ 0079: auto-confirm stale matches (14 days, so nobody's rank waits forever)
→ 0127: doubles needs one confirmation per side
The PM lesson for me: don't try to design the perfect data model up front. Make change cheap, write the rule down when you learn it, and ship the migration.
Builders: how many of your migrations were planned?
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Challenges
View all
Related posts
A clean-looking CSV can still lose information during migration.
I built Migration Control, a self-initiated Python demo that accounts for every row: ambiguous records go to a traceable review queue, refunds stay in the totals, currencies remain separate, and unknown amounts remain unknown.
The synthetic fixture reconciles $185.34 into $82.34 accepted + $103.00 quarantined. Its second local target run produces six NOOPs with the same fingerprint. All 23 regression tests pass, plus a separate SQL totals check.
The target is a local simulation, not a live CRM integration. The useful design decision: make uncertainty visible before importing.
SQL join integrity — synthetic demonstration. A SQLite exercise preserves 4 source deals and the 45,000-cent total while a naive association join inflates the sum to 80,000 cents. Ambiguous primary links, missing references and a null amount are surfaced. Equal-value legitimate deals remain distinct; reruns produce identical output. This is a local technical exercise, with no customer data or live HubSpot connection.
From 2.5 hours of research a week to 30 minutes of review.
Finding funding opportunities was a repetitive process: open a link, find the deadline and funding amount, check eligibility, and decide whether it was worth pursuing.
Around 5 minutes per opportunity. Across 30 opportunities a week, that adds up.
I automated the process using Make + OpenAI.
Here’s how it works:
Trigger: A user submits a link or screenshot.
Extract: The workflow fetches web pages and PDFs, or uses OCR for screenshots.
Process: Rules route each input to the right path.
Evaluate: OpenAI extracts key details and scores the opportunity against the user's profile.
Validate: Unreadable pages trigger a screenshot fallback. Invalid opportunities are rejected, and missing details are marked “not specified.”
The key design decision? Keep the AI in its lane.
Rules handle routing. AI handles extraction and fit scoring. Missing information stays missing instead of being guessed.
It’s not fully hands-off. Funding pages vary, and some results still need human review.
But the time spent went from roughly 2.5 hours to 30 minutes per week.
That’s what good automation should do: remove repetitive work without removing human judgment.
Want to see how the workflow is structured? Comment “wired” and I’ll share the workflow map.
#Automation #Make #OpenAI #LowCode
Love the decision to keep rules in control and use AI only where it adds value. Especially the part about not guessing missing information. That’s what makes automation reliable.
