A four-person team behind everyone's data at a custom gear shop
Custom Ink helps organizations and businesses of all sizes design and order custom apparel and merchandise including team shirts, company swag, and fundraiser gear. Behind that sits a data organization that punches well above the company's over 500-person headcount.
Brett Petersen is Director of Data and Metrics, leading the analytics engineering function at Custom Ink. His team of four builds the Fivetran, dbt, BigQuery, and Looker infrastructure that the rest of the data org runs on.
"My team's role is basically to act as the enablement platform for our entire data analytics organization, as well as our machine learning organization," says Brett. That means supporting around 25 data scientists, data analysts, machine learning engineers, and a dbt project that has grown past 1,000 models.
The executive leadership at Custom Ink instills a data-driven culture across the company. By using dbt platform, the team has built a single data foundation that powers analytics, near real-time business telemetry, and machine learning models that deliver better experiences to customers.
The cost of rebuilding what hasn’t changed
Last year, the Custom Ink team moved to dbt platform as their primary scheduler and deployment system to simplify managing their growing dbt project. This year, they're focused on dbt State to streamline costs and developer efficiency.
Before dbt State, the team orchestrated their 1,000-model project across several separate jobs, each tagged to trigger a specific portion of the DAG on its own schedule. Keeping the most critical sources current meant critical models rebuilt far more often than they needed to which added warehouse cost.
Layered on top was source freshness gating. The team configured jobs to build only when upstream source data had refreshed, a reasonable instinct that got harder to maintain across a project that size. "It was a very complicated source freshness setup that we had," says Brett. "We had a lot of noisy freshness alerts."
Down to one deployment job, running frequently, and freshness that lives on the model
dbt State changed the unit of decision. Rather than a job deciding what runs, dbt State evaluates each model and decides whether to build, skip, clone, or auto-defer based on whether the output would actually change. For the Custom Ink team, dbt State setup took seconds. "It was super easy to set up," Brett says. "You just turn it on and it gets to work."
After the initial setup, the Custom Ink team spent time tuning dbt State to their business needs. This eliminated the complicated source freshness configuration from their prior orchestration approach. Freshness now sits on the model via codified dbt State configurations and rule dependencies. Custom Ink is using dbt State’s lag_tolerance, a max staleness window, so models rebuild only when they're due, not every run. Now, parts of the DAG refresh every 30 minutes, others every two hours, and the team is working toward 15 minutes for the most time-sensitive sections. dbt State simplified CI/CD runs, too.
For Custom Ink, that collapsed the orchestration layer. "We've been able to simplify our previous setup down to one run, which is amazing, because it's a very clean deployment," says Brett. "Everybody knows what's going to run. There's no confusion."
A vastly underrated developer experience
The savings are what help get dbt State signed off by leadership. What Brett describes as the bigger change is the developer experience. Some of that follows from the single deploy job.
Custom Ink leans heavily on AI-assisted development. Most of the team works in VS Code with Claude, with Slack autotriage wired into their alerts, and Brett himself runs five Claude agents rather than working in an IDE. One clean job flow makes that tractable. "Because we only have one run, it's more efficient, and we can interact with Claude and look at the job and debug what's going on. All we had to do was point Claude at the dbt State docs."
The better developer experience is giving Brett and team significant time back, Brett says. “Once you tally it all up, it's roughly 10 hours a week back for the team. A big chunk of that is our on-call person, who used to spend time checking for race conditions in the data caused by competing dbt runs. That's just gone now.”
From manually enforced to codified governance in development
The larger shift is that deferral stopped being something developers have to know about. dbt State handles deferral, cloning, and reuse automatically, so the thing analysts used to have to configure, and at times would forget to configure, disappeared.
"You kind of get deferral for free now," says Brett. "Previously, our team would have had to make sure defer was turned on. Now it all happens magically for them behind the scenes. I haven't had any questions about that since we turned on dbt State a couple of months ago."
That matters most for Custom Ink’s data analysts, who are the majority of their dbt users. "I don't think many of them appreciated what was actually going on behind the scenes when they were using defer before, but now they don’t even have to think about it."
The same shift gave analysts direct control over refresh cadence. "Because they have complete control to set that lag tolerance, they have much more granular control over when their models run. Where before, the team was purely taking it when the source data refreshed, not necessarily with the cadence we needed."
The result is less firefighting. "We're not debugging as many things unnecessarily."
Before dbt, users at Custom Ink built models and data products off of an ungoverned data warehouse and sometimes directly off production databases, resulting in inconsistencies and breaks in data products relied on by stakeholders, so Brett and team put permission blocks in front of source data to stop it from happening again. "With dbt State doing the cloning and reuse automatically, I see a world where we rethink our access control architecture to enable the team to move even quicker while maintaining strong governance.” Brett says. “The guardrails are just in the infrastructure now, whether it's an analyst or an agent doing the work."
Lower spend, hours back, and one clean run
Two months in, dbt State has reduced Custom Ink's monthly BigQuery bill attributed to dbt workloads by 42% against what the same workload would have cost without it. The orchestration layer that used to span several tag-triggered jobs is now a single run. And the team is getting back more than 10 hours a week, much of it on-call time that used to go to checking for race conditions between competing dbt runs.
The savings are what get the decision made. The simplified orchestration and more efficient developer experience is what changes the work.
"The developer experience with dbt State is vastly underrated. We went from several jobs and a very complicated source freshness setup to one clean run where everybody knows what's going to run. Also, we used to have to enforce governance on development by hand. And that's all on top of spending 42% less on our dbt builds in BigQuery than we would be without it."
What's next
But it doesn’t end there, Brett says. “As we start to plan for 2027, I expect we’ll continue to refine our dbt Mesh architecture to give our various product and operations analytics teams more granular control over their own projects. I don’t think this would have been possible without dbt State thanks to the simplifications we’ve been able to make in the orchestration across all of our projects as a result.”
