A software engagement with Dazlab starts with discovery, turns what we learn into written specs, and builds against those specs with AI-assisted engineering and review on every change. You decide what gets built and when it goes live; we decide how it's built and tell you plainly when we think something is a bad idea. We launch when the product, the content and the pages agree, and the work usually carries on after launch.
We're a product studio first. We build and run our own products, and take on a small number of client projects alongside them. This post explains what working with us looks like.
Why we take on client work at all
Dazlab builds niche software for specific industries. Our own products are Handl for agency financial ops, Mortar for interior designers, Arbeo for hiring, and TaliCMS for real estate associations.
Client work is selective. We take it on when the problem is specific and we can bring something real to it: an existing platform, a pattern we've already built, or a strong view on how the product should work. That's why many of our client projects sit in industries we already know, like real estate associations and real estate recruitment.
It also means the way we build for clients is the way we build for ourselves. Same process, same review, same people.
Discovery first
Every engagement starts with understanding the problem before touching any technology: who the users are, what they're trying to do, what's getting in the way, and which assumptions haven't been tested yet.
The output is a clear view of what to build first. Not the biggest possible version, and not the smallest. The right one to test your core assumptions with real users. If we think part of your brief shouldn't be built yet, we'll say so. Our post on how to scope a SaaS MVP explains how we think about that.
Discovery is also where we work out what can be reused. For associations, a lot of what they need (member directories, events, document libraries, property search) already exists in TaliCMS. Columbus REALTORS® went live in twelve weeks because nobody had to invent those parts on their budget. The work was configuration, design, content migration and the data feed.
Written specs
Once we know what to build, it gets written down. Every piece of work becomes a ticket in Linear that says what's needed, what "done" looks like, and how we'll check it.
That's how we run our own products, and it matters even more on a client project. A written spec means:
- You can see what's being built before it's built.
- Decisions don't live in someone's memory or a call nobody minuted. If it needs to outlive the conversation, it goes in the ticket.
- The AI agents that do much of our building work against something precise, so they build the right thing first time.
We describe this in more detail in spec-driven development with AI agents.
How we build
We use AI-assisted engineering, not vibe coding. AI coding agents write a lot of the code, but inside an engineering process: written specs, tests that must pass, review on every change, and a stronger adversarial review on anything touching money, logins or customer data. People decide what ships.
The full workflow is in how a small studio ships 100+ changes a week, and the distinction is in AI-assisted engineering vs vibe coding. For a client, the practical effect is that small, checked changes reach you quickly, rather than arriving in one big batch at the end.
Fixed scope or time and materials
There are two common ways to structure a software engagement. Both are legitimate. They suit different situations.
| Fixed scope | Time and materials | |
|---|---|---|
| What's agreed up front | A defined set of deliverables | A way of working and a rate of effort |
| Best when | The scope is well understood and unlikely to move | You expect to learn and change direction as you go |
| Your risk | Paying for a contingency buffer; changes need a formal variation | Total cost moves with what you decide to build |
| Our risk | Underestimating | Low, which is why you should expect transparency in return |
| Changes | Handled as scope changes, re-agreed | Absorbed into the plan and reprioritised |
| What makes it work | A thorough discovery and a precise spec | Clear priorities and regular visibility of progress |
The honest trade-off: fixed scope gives you budget certainty and costs you flexibility. Time and materials gives you flexibility and asks you to manage priorities actively. Which one fits depends on how well the problem is understood when we start, and we'll tell you which we think suits your project and why.
For a broader comparison of engagement models, see fixed price vs time and materials vs dedicated team. We don't publish engagement prices; every project is scoped individually.
How changes are handled
You will change your mind during a build. Not because you're indecisive, but because you'll learn things you didn't know at the start. That's the point of building.
When something changes, it becomes a written ticket like everything else, so there's a record of what changed and why. Under fixed scope, a change is a scope change and gets agreed before it's built. Under time and materials, it goes into the plan and we reprioritise together. Either way, nothing gets built on the strength of a passing comment.
Who decides what
Clear roles avoid most of the friction in a client project.
You decide:
- What problem we're solving and for whom
- Priorities, and what gets built first
- When something goes live to your users
- Anything that's about your customers, members or brand
We decide:
- How it's built: architecture, code, tests and review
- What standard a change has to meet before it ships
- When to push back. If we think a request will hurt your users or your product, we'll say so and explain why. Then it's your call.
Together: the spec. You bring the knowledge of your business; we bring the knowledge of how software like this works and fails.
Launch
Shipping and launching are different things. Code can be merged and deployed well before anything is announced. We launch when the product, the content and the pages all agree.
Launch week itself is mostly about the things users and search engines notice first. When the Abilene Association of REALTORS® site went live, we spent the following week making sure every old link forwarded to its equivalent on the new site, so bookmarks, emails and search rankings carried over; wiring up the contact form; tidying the sitemap so only real pages get indexed; and making sure the events calendar always looked finished. Before cutover, we'd crawled and archived the old site and mapped old addresses to new ones, and after launch we re-checked every link and asset.
After launch
A launch is the start of a product's life, not the end of the project.
On our client platforms, the work typically continues after go-live. In the weeks after Texas REALTORS® launched, sponsors got banner performance reporting and site search got smarter. Columbus REALTORS®'s open-house listings page got noticeably faster. On Real Estate Jobs Australia, we keep working with the client on the platform and on growth, from employer hiring tools to SEO and lead-generation pages.
Just as important, clients run their own sites day to day. Association sites live or die on staff being able to update them without calling a developer, so on our TaliCMS projects the association's team manages pages, events and links themselves.
What ongoing support looks like is agreed per project, based on what the product needs and what your team wants to own.
What a client says
"Our new site on TaliCMS has handled the scale of a state association without missing a beat. Dazlab worked closely with our team through the build and launch, and the result is a site that's faster and much easier for our staff to keep current." — Angela Brutsche, CAE, RCE, Vice President of Communications & Marketing, Texas REALTORS®
You can see more of the work on our Texas REALTORS® and Columbus REALTORS® pages.
FAQ
What kind of projects does Dazlab take on?
Niche software for specific industries, where the problem is clear and we can bring real experience: an existing platform, a product we've built, or a strong view on how it should work. We take on a small number of client projects alongside our own products.
Do you work fixed price or time and materials?
Either, depending on how well the scope is understood at the start. Fixed scope suits well-defined work; time and materials suits projects where you expect to learn and change direction. We'll recommend one and explain why.
How do you handle changes mid-project?
Every change becomes a written ticket so there's a record of what changed and why. Under fixed scope it's agreed as a scope change; under time and materials it's reprioritised into the plan.
Do you use AI to build client software?
Yes, inside an engineering process: written specs, tests that must pass, review on every change, and stronger review on anything touching money, logins or customer data. People decide what ships.
What happens after launch?
Usually more work. We fix the launch-week details, keep improving the product, and agree ongoing support per project. On content platforms, your own team runs the site day to day.
If you have a specific problem worth building for, tell us about it.
Consulting Inquiries
