DataPrep Studio
A data cleaner that never uploads your file
Results — hover any figure for the baseline and the caveat
Formats read and written
CSV, TSV, JSON, Excel and MARC, in both directions. Delimiters are detected and quoted fields containing separators are parsed correctly rather than split.
Reversible operations
Trim, case, find and replace, split and merge columns, rename headers, filter, deduplicate, standardise spellings — each undoable. Reversibility is per step, not a full version history.
Network calls with your data
No telemetry, no analytics, no account. The app keeps a local note of when the trial started and computes a hardware identifier that licence keys bind to; neither contains any of your data, and the identifier only leaves the machine if you email it to request a key.
Rust crates, licences reproduced
Plus 143 npm packages. Every one has its licence and copyright notice reproduced in THIRD-PARTY-LICENSES.md — the boring half of shipping proprietary software built on open source.
The problem
The people with the messiest data are usually the people who can't write code to fix it — librarians, administrators, analysts working out of spreadsheets. Their two options are both bad. A spreadsheet will happily destroy the data on open: leading zeros vanish, long identifiers become floating point, dates get reinterpreted. A cloud cleaner solves that but requires uploading the file, which for patient records, student records or catalogue data is often simply not allowed.
What I built
A desktop application, so the file never moves, with a Rust engine that treats every value as text and never infers a type on the user's behalf. The engine is columnar and lazy: an operation records itself into a query plan and only materialises the rows the viewport is actually showing, so a million-row file stays interactive instead of blocking on each edit. Above it sits a TypeScript interface where all thirty-plus operations are undoable and every ambiguous decision — how to compare a column, where blanks sort — is asked rather than guessed.
The table
| Operation | Time |
|---|---|
| Open a CSV | 3.8 ms |
| Count rows | 17 ms |
| Jump to row 500,000 | 82 ms |
| Filter (125,225 rows kept) | 189 ms |
| Remove duplicates | 262 ms |
| Profile a column | 430 ms |
| Export 38.5 MB CSV | 71 ms |
Measured on 1,000,000 rows — 13th Gen Intel Core i7-13700H, 15.7 GB RAM. One machine, one dataset; treat these as the shape of the engine's behaviour rather than a benchmark suite.
What the results actually say
Holding every value as text is the entire product.
Type inference is the feature that corrupts data. A spreadsheet reads 007 as a number because it is trying to help, and the help is unrecoverable once the file is saved. Refusing to infer costs some convenience — you have to tell the sorter whether a column is numeric — and buys the guarantee that what comes out is what went in.
Lazy evaluation is what makes it feel fast, not raw speed.
Opening a million-row CSV in 3.8 ms isn't parsing a million rows quickly; it's not parsing them at all until something needs them. The work moves to the operations that genuinely have to touch every row — deduplication at 262 ms, profiling at 430 ms — and those are the ones with a progress state.
Shipping a product is mostly the questions code doesn't answer.
The engine was the interesting part; the release was licence keys bound to a hardware ID, a trial that locks the application without holding the user's files hostage, SHA-256 checksums, 772 third-party licences reproduced, and a README that admits SmartScreen will flag an unsigned binary. None of that is engineering, and skipping any of it would have made the download untrustworthy.
What this doesn’t prove
- Windows 10 64-bit and later only. There's no macOS or Linux build, and the installer is per-user rather than system-wide.
- Not code signed yet, so SmartScreen warns on first run. Until there's a certificate, the only verification on offer is the published SHA-256 checksum.
- Tested up to one million rows. Larger files are expected to work but haven't been measured, and peak memory use isn't instrumented — so no memory claim is made at all.
- This repository distributes the compiled application; the source is private. An engineer reading this can run it and check the numbers, but cannot review the engine — which is a real limitation of it as portfolio evidence, and the reason the case study is written around measurements rather than code.
- Version 0.1.0 with a handful of downloads. It works, but it has not been through the kind of use that finds the interesting bugs.
This section is here on purpose. A result without its limits isn’t a result, it’s a claim.