We build data pipelines, automate manual work, and create reporting that businesses actually use. These are the stories of what happened when they did.
Every engagement starts the same way: we look at your actual data before recommending anything. What we build depends entirely on what we find.
The case studies below show three different kinds of problems. The first is a focused analytics engagement for a small eCommerce retailer where a single Power BI analysis revealed that 72% of customers were being overcharged for shipping, a problem hiding in plain sight in the transaction data. The fix was straightforward once identified, and the purchase rate increased 74% within weeks of the correction.
The second is a longer-running technical build: a complete data pipeline and public-facing map that ingests raw city permit and planning data from Greenville’s ArcGIS feeds daily, cleans it, and serves it to an interactive map. The underlying data came with wrong coordinate systems, all-caps permit codes, and plain-text homeowner information — none of it usable out of the box. The case study documents how we built the pipeline to fix all of that automatically.
The third goes underneath that pipeline: what 292 permit-issuing jurisdictions within 150 miles of Greenville actually look like up close, and why fewer than one in four of them is reachable as structured data at all. It's the receipts behind every coverage claim on this site.
In every case, the starting point was understanding the data problem clearly before writing a single line of code. That’s the approach we bring to every engagement, regardless of industry or scale.
74%
Purchase rate increase after shipping correction
A Power BI shipping analysis connected eBay transaction data to USPS rate tables, revealed systematic overcharging, and drove a measurable conversion improvement within weeks. Full technical build documented inside.
Read the Full Case Study
1 City Feed → 10 Permit Systems
Wrong coordinates, all-caps codes, and ten jurisdictions that each publish differently. Unified into one privacy-respecting public map.
A complete data engineering case study: Azure Functions, Azure SQL, GeoJSON, and MapLibre GL JS combine permit feeds from ten systems across five Upstate SC counties into a clean, filterable, privacy-respecting public map rebuilt daily — and the data product built on top of it.
Read the Full Case Study
292 Probed → 11 Usable
Ninety-one jurisdictions have no online portal at all. The rest can't agree on what to call an apartment building.
A data-quality deep dive: 292 jurisdictions probed within 150 miles of Greenville, 448 permit-type dialects reduced to 12, and the silent failures that never announce themselves (a parcel API returning HTTP 200 on error, a feed frozen for months behind a live-looking endpoint).
Read the Full Case StudyAll three case studies above followed a consistent pattern: we spent time in the data before prescribing a solution, built a minimum viable version quickly, measured the result, and iterated. That’s the same process we use for every client engagement, regardless of industry or project size.
If you’re evaluating whether we’re a good fit, reading these case studies is the best way to understand how we actually work: how we approach messy data, what we build, and what results look like. If your situation looks similar, reach out and we’ll tell you what we’d do with your specific data. If your industry or problem type isn’t represented yet, that doesn’t mean we can’t help — we work across a wide range of industries and problem types.