CDBTech, LLC

Yes, and for the first time in nearly a decade. My work has been primarily referral-based, but I currently have availability for new clients looking for custom website development, platform development, or technology consulting.

My current hourly rate is $155. Fixed-price projects generally cost between $3,500 and $15,000.

All work is billed in USD.

Sometimes. It depends on a number of factors:

• The age and complexity of the codebase
• The quality and availability of documentation
• How difficult it is to test and verify changes

Taking on an existing project is a decision I make case by case. If you have an existing codebase you’d like help with, the best first step is to get in touch and share some context.

I offer fixed project pricing for work I’ve been involved in from the start, where I’m familiar with the codebase and can vouch for its quality.

All other work can be done on an hourly basis.

Not explicitly, though in practice there’s not much work that I can do in under seven hours.

I typically require a deposit of around 20% to begin work. An additional sum may be payable at the midpoint, and the balance is due on completion.

Payment terms will be clearly stated in any project proposal I provide.

For fixed-price work, I invoice per our agreed-upon payment terms.

For hourly work, I invoice at the end of the month.

Yes, I have a general contract, applicable to any work we do together. The goal of my contract is to ensure we both understand our responsibilities, not to deceive you. As such, it’s written in plain English and available in a version controlled GitHub repository for you to review at any time.

For fixed-price work, I will also submit a project proposal, outlining the scope, timeline, and price for the individual project.

When you reach out, it helps to share:

• What you need to accomplish — e.g. “We’re launching a subscription box service and need a sales site, a customer account dashboard, and admin tools to manage fulfillment.”
• How you think it might be done — e.g. “We’ve heard there are plugins that could help, but we’re not sure.”
• What you’ve already done — e.g. “We have a business plan, the domain, and some copy.”
• Your timeline — e.g. “We’re hoping to launch in three months.”
• A rough budget — e.g. “We’re aiming to launch for under $30k, with a post-launch feature list we can revisit.”
• Any relevant context — e.g. “We have deep experience in operations and fulfillment, but this is our first time building on the tech side.”

You don’t need to have all of this figured out - a rough picture is enough to start a conversation.

You do. Once final payment is made, ownership of all code and assets that can be transferred to you, is transferred to you.

That said, there may be third-party licenses or agreements in place that limit your ownership of specific assets or libraries - those restrictions aren’t mine to waive. I’ll flag anything relevant during the project.

You can review the full copyright terms in my general contract.

My focus on any project is honoring what we agreed to — delivering quality work that fulfills the scope, on budget and on schedule.

Minor scope changes can usually be absorbed without much impact on either. Larger changes will typically require a change order that documents the adjustment and its effect on budget and timeline.

My preference is to launch the project as originally scoped whenever possible, and treat additions as roadmap work to tackle afterward. In my experience, this keeps projects on track and gets work live faster — which is a win for everyone.

A full site development project typically takes 6–9 weeks for design, development, and review. Coding a provided design can take a few weeks less.

I try to turn around hourly work items within 2–4 business days, though this varies based on complexity and my current workload.

Platform projects are larger and typically estimated in quarters to completion.

Documentation is part of every project discussion. The right format depends on what you actually need. It could be a documentation microsite, a whitepaper, a Q&A reference doc, or simply a working session where I walk you through what was built and how to use it.

On the code side, I write modular, clearly named code that’s meant to be readable and maintainable by anyone who works on it after me. Please bring up your documentation expectations early in the project so I can plan accordingly.

I’ve worked with many designers over the years, on both CMS-driven sites and more complex web applications.

If you have a designer - in-house, freelance, or otherwise - I’m happy to collaborate throughout the process:

• I can clarify exactly what I need to build each scoped feature, and identify which elements I can derive from existing mockups without requiring additional design work.
• I can review designs early to flag anything that may be harder to build than expected, could cause accessibility issues, or might not hold up well with real content and use cases.

When building from a design, I try to balance close adherence to the mockups with the practical realities of a live website - performance, manageability, and graceful handling of content that doesn’t always fit neatly into a comp.

I’ve worked with many agencies over the years, completing hundreds of website and platform development projects. Most agency relationships follow a consistent process:

1. The agency sources the client and handles initial discovery to confirm project fit and general requirements.
2. I’m brought in early to assess feasibility of scope, timeline, and budget, and to answer technical questions.
3. The agency’s designer produces mockups of key pages and visuals. I review the designs to flag anything unexpectedly complex or problematic before they’re finalized.
4. The agency, designer, and client finalize and sign off on the designs.
5. I build the site, set up the server and infrastructure (hosting, CMS, email routing, firewall, etc.), and handle initial testing. I stage the site with sample content to validate the designs, then hand it off to the agency with relevant documentation.
6. The agency handles content per their agreement with the client.
7. The client reviews. We address changes collaboratively, typically across two rounds of revisions.
8. With client approval, I launch the site and verify everything in the live environment.
9. I provide ongoing support and further development as needed.

Most agency work is billed hourly, since these are typically ongoing relationships with multiple projects at various stages simultaneously.

I offer white-label services at no added cost. With a sending email address, I can correspond with clients under your brand.

Agency projects are credited to the agency. I include agency work in my portfolio unless we agree otherwise in advance. I’ll charge a modestly higher rate for work I can’t show publicly.

Browser support is less of a concern on the modern web than it used to be. The elimination of Internet Explorer and the standardization of browser engines have made cross-browser compatibility largely a solved problem for most projects.

That said, I test in the current stable versions of the major desktop browsers as well as on mobile devices. Specific support requirements are defined in my contract, and if you have users on unusual or legacy environments, we can discuss that during planning.

I always build testing time into project estimates, both for my own review before presenting work and for your review before signoff.

You can check out my GitHub profile for some recent code I’ve written. The majority of my work is for clients, so I don’t own that code and can’t share it publicly.

No site is 100% secure in all circumstances, but I do my best and am confident in the products I deliver. Security is a multi-faceted issue, and I try to address every aspect, including:

• Making sure your site is on quality infrastructure
• Making regular backups and ensuring the backups are usable
• Writing good code, with version control
• Keeping third-party dependencies updated and monitoring for known vulnerabilities
• Managing secrets through environment variables, never hardcoded in source code
• Implementing proper authentication and session management
• Sanitizing user data inputs
• Rate limiting on forms and API endpoints to prevent abuse
• Setting secure HTTP headers (Content Security Policy, HSTS, etc.)
• Using encryption as appropriate
• Encouraging security best practices, like using strong passwords, rotating credentials, and following the principle of least privilege

Sparingly. LLMs are powerful tools, but prone to mistakes — and outright fabrication — when not closely supervised. I find them most useful for:

• Discrete, verifiable code tasks — e.g. “Sort this array of objects by year, descending, nulls last.”
• Augmenting QA — e.g. “Review the error messages in this project for consistent tone, appropriate for a non-technical audience.”
• Rubber ducking — e.g. “I want to build a real-time vector search over 1M+ records. My plan is to ______.”

I review any LLM output that goes into a client project manually, line by line, before it’s committed.

Probably not much. I’ve worked with dozens of hosts over the years, and most are pretty awful — slow, running outdated software, and charging a premium for their shortcomings.

These days, I prefer to host directly on cloud services like DigitalOcean or AWS, and use a deployment system to manage the server. For WordPress sites, that’s SpinupWP. For custom platforms, it’s usually Dokku.

This approach strikes a good balance between maintaining direct control over the server and offloading routine tasks like deployment, backups, and updates to a trusted tool.