David Dacruz

Services

I make hard technical decisions and stay to implement them.

I work directly with small teams on AI systems, software products, and difficult releases. I define the risk, choose the smallest sound path, and build with the people who will own it.

Discuss a project Services

Services

Start with the problem in front of you.

AI Opportunity Audit

I audit one workflow, rank the opportunities, and hand you a 30-day action plan before a build starts.

  1. The problem

    One workflow is costing time or accuracy. The team knows it hurts, but not whether the answer is AI, simpler software, or a process fix.

  2. My job

    I map the inputs, decisions, handoffs, and failure points. Then I rank each change by value, effort, risk, and required human control.

  3. The outcome
    • Workflow findings
    • 3–7 ranked opportunities
    • Recommendation detail
    • 30-day action plan

AI systems

I build AI workflows around the way your team already works, with a human on the decisions that matter.

  1. The problem

    Manual research, support, reporting, or follow-up is slow, inconsistent, and split across tools.

  2. My job

    I connect the data, automate testable steps, log important actions, and require approval where the cost of a mistake is real.

  3. The outcome
    • AI workflow design
    • Knowledge bases and retrieval
    • Integrations with the tools you already use
    • Testing, safeguards, and human approval

Product engineering

I turn a product decision into working software, then stay for launch and the first hard lessons.

  1. The problem

    The idea is clear in a meeting. The interface, data, architecture, and delivery plan still disagree.

  2. My job

    I define the smallest release worth shipping, build the end-to-end path, and document trade-offs before they become expensive.

  3. The outcome
    • Product definition and technical plan
    • Full-stack web applications
    • APIs, data flows, and integrations
    • Launch, analytics, and iteration

Technical direction

I step in when a product needs a hard technical decision, a recovery plan, or a release that cannot drift.

  1. The problem

    The team is shipping, but unclear architecture, ownership, or delivery risk is slowing the next decision.

  2. My job

    I stay close to the product and code, challenge risky assumptions, record the decisions, and help ship the critical path.

  3. The outcome
    • Architecture and delivery reviews
    • Roadmap and scope decisions
    • Technical due diligence
    • Hands-on support for critical releases

Technical publishing & discovery

I make technical work easy to find, understand, and verify—without writing for robots.

  1. The problem

    The product works. Its website, evidence, and explanations do not prove it.

  2. My job

    I fix the information architecture, performance, structured data, source trail, and copy. Then I measure what people and search systems can actually reach.

  3. The outcome
    • Information architecture and crawl paths
    • Structured data and source records
    • Technical content models
    • Performance and discovery diagnostics

Technical writing & publishing

I turn code, interviews, and evidence into technical articles, documentation, and reports people can use.

Technical writing pricing
  1. The problem

    The knowledge is in the team and codebase. The reader still cannot act on it.

  2. My job

    I inspect the source material, interview the right people, verify the claims, write the piece, and carry it through technical review and publication.

  3. The outcome
    • Technical articles and explainers
    • Product and developer documentation
    • Research-backed technical reports
    • Editing, diagrams, metadata, and CMS publishing

Working together

Make the risk visible. Ship the smallest useful proof.

The people making product decisions stay close to the work. I start with the riskiest useful slice and document what the team will inherit.

DD / SYSTEMS

Software decision loop

Every release creates evidence for the next decision.

  1. 01 Frame

    Define the outcome, constraints, and people affected.

    users · system · context
  2. 02 Decide

    Make trade-offs explicit and choose a reversible path.

    risk · ownership · scope
  3. 04 Observe

    Measure behavior, failures, and what the team learns.

    signals · feedback · recovery
  4. 03 Build

    Ship the smallest useful slice with controls in place.

    code · tests · release
I use the same loop for product decisions, system design, and delivery.

Good fit

The work is concrete, even if the answer is not yet obvious.

  • There is a real product, workflow, or decision that needs to move.
  • You want senior technical thinking and hands-on implementation from the same person.
  • You are comfortable starting with a small, useful version and improving it from real feedback.
  • You value clear trade-offs, visible progress, and a clean handoff.

Not a fit

The project needs a different kind of team.

  • The project requires a large outsourced delivery team.
  • The goal is only to add an AI label without changing the product.
  • No one is available to make product decisions.
  • Success depends on claims that cannot be supported.

Common questions

The questions I hear most often.

Straight answers about the work, my background, and when an engagement makes sense.

What do I build?

I build AI workflows, web products, and the technical foundations behind them. I can take a messy problem from the first decision to working software—and leave the team with a system it can run.

Where am I based?

I am based in Ericeira, in the Lisboa region of Portugal. I work with teams across Europe and remotely.

What kind of project is the best fit?

A real product, workflow, or technical decision with an accountable owner. We can start small, but someone must be able to make product decisions and give access to the evidence.

How do I approach an AI system?

I start with the work: who owns it, what information moves, where decisions fail, and what a mistake costs. AI goes only where it can be tested. Permissions, review, logs, and recovery are part of the build.

Can I work as a hands-on technical lead?

Yes. I can set architecture and delivery direction while staying close to the critical code, product behaviour, and release path.

Do I work on Bitcoin and Ordinals products?

Yes. My public work includes Pizza Ninjas, Pizza Pets, and Project Spartacus, covering inscription pipelines, recursive assets, on-chain systems, and mempool-aware operations.

Have I shipped Ethereum smart contracts?

Yes. For Yakuza Inc., I owned the ERC-721 contract and mint pipeline from allowlist through public sale. The 3,223-token launch collected 321.4 ETH through the contract.

An unfinished problem is enough.

Tell me what is blocked, risky, or costing the team time.

Discuss the project