Building withoutBG Since 2019#

Where it started#

I started withoutBG in 2019, four years before LLMs became a default shortcut for building software. At the time I was writing almost exclusively in Python. No React, no Rust, no production web stack. Just reading papers, training models, and trying to make background removal work on real photos instead of benchmark thumbnails.

Background removal looked solved from the outside even then. Upload an image, get a PNG back. In practice, edge quality, hair, glass, motion blur, and the gap between training data and user photos made it a hard engineering problem, not a one-week fine-tune.

Research, experiments, and benchmarks#

I read the major papers in image matting and background removal, then ran my own experiments on top of them. I can count more than 300 runs in my experimentation platform. That number is not a brag. Many of those runs were dead ends: better quality but worse latency, good on academic test sets and bad on Shopify product photos at 2 a.m.

I have always benchmarked withoutBG against paid services and open-source alternatives, not just against my own previous version. That habit is how I know where the models actually stand. Results are published in Compare and in the alpha matting evaluation benchmark. I would rather show numbers than marketing screenshots.

Today, withoutBG produces better and tighter edges than most alternatives I test against, with shorter inference times on comparable hardware. That is true for the hosted pro model in production. The open-weight snap model is better than many paid options in some categories, and worse in others. I publish those trade-offs instead of flattening them into a single ranking.

The dataset is the hard part#

Models get the attention. Datasets do the work. Building a matting dataset that generalizes to real user photos is the most challenging part of this project, and the part least visible from the outside.

I built a mobile application to review and curate training data on the go: commuting, waiting in a queue, any spare ten minutes. The pipeline creates samples automatically; I curate along the way, rejecting bad edges, fixing labels, and catching failure modes before they reach training. It is slow, manual, and exactly the kind of work that does not show up in a launch tweet.

I also reinvested revenue into human annotation. I hired annotators in different countries and paid them properly. That was a significant investment, not a crowdsourcing side quest. Good matting data is expensive because bad matting data is free and useless.

I wrote more about the process in creating an alpha matting dataset and published withoutBG100 as a public evaluation set.

Infrastructure#

The hosted API runs on AWS. I received AWS credits that helped keep infrastructure costs manageable while the product was still finding its footing. The stack is heavily optimized for inference cost and latency, not for looking impressive on a architecture diagram.

Production inference runs on AWS Inferentia, purpose-built ML inference chips. That choice trades flexibility for predictable cost at scale. p95 latency matters more to API customers than peak FLOPS on a slide.

What changed when AI tools arrived#

LLMs did not build the models. Six years of Python, papers, and failed experiments did. But AI-assisted development accelerated everything around the models: this website, documentation, billing flows, and the product surfaces that let people actually use what I trained.

That acceleration let me ship the open-weight model through more channels than I could have managed alone in 2019:

• Python package and Docker images
• CLI tools and a Mac app (Rust, for performance-sensitive local inference)
• Figma and GIMP plugins
• Model variants tuned for different applications (stickers, e-commerce product photos, general cutouts)

The open-source model existed before AI coding tools. The distribution layer around it got much better after them.

What I actually built#

Over six years, withoutBG grew from a research side project into two offerings: a hosted API and an open-weight model you can run yourself. Both exist because I kept iterating on the same core problem: high-quality image matting at a cost and latency that makes sense in real products.

• Models: training, evaluation, and deployment of background removal / alpha matting models.
• Research: papers, benchmarks, evaluation sets, and notes in Tech.
• Product: REST API, account and billing, documentation, this website, integrations, and the distribution channels above.
• Operations: AWS infrastructure, monitoring, incident response, and keeping latency predictable.
• Support: when something breaks for a customer, I am usually the person reading the email and fixing it.

I am not claiming I wrote every dependency or invented the underlying research. Open source depends on contributors, libraries, and papers I did not write. But the product direction, the trade-offs, and the responsibility are mine. The technical version of the training loop is in Engineering Background Removal.

The “we” thing#

One thing people noticed in older emails: I sometimes wrote we when I meant I. That was a habit, not a lie about having co-founders, but still misleading.

There is no team behind the day-to-day work. I built most of this myself. When I wrote “we,” I was trying to sound like a company. I am not hiding that anymore.

Solo founders often use “we” because it sounds more credible. I did that too. Going forward, I will say I when I mean I. The product and the legal entity still operate under the withoutBG name. That part is real. The imaginary team was not.

What is real, what is not#

• Real: the API, the models, the open-source repo, paying customers, AWS Inferentia in production, and the legal entity on the imprint.
• Real: 300+ experiments, published benchmarks, and a dataset built over years of curation, not scraped overnight.
• Not real: a large in-house team, a 24/7 support desk, or a corporate voice pretending this is a 50-person company.
• Not real: the implied “we” in older emails. That was me.

Why I am sharing this now#

Reddit threads and Hacker News comments ask fair questions: Is this a wrapper? Is there actually a model? Who runs it? Can I trust a solo project in production?

You should ask those questions. I would rather answer them directly than let people guess. Solo does not mean fake. It means one person is accountable, which cuts both ways: you get direct access to the person who built the thing, and you also get the limits of one person's bandwidth.

If you use withoutBG, you are betting on my continued work and judgment. I think that is worth stating plainly.

Reach me#

Questions, bug reports, or honest feedback: contact form or contact@withoutbg.com. You will reach me, not a support queue.

Code and issues: github.com/withoutbg/withoutbg

Imran Kocabiyik, Berlin