David Dacruz

Capabilities

Senior judgment from someone who will still write the code.

I scope the work, make the technical trade-offs, and build alongside the team. Most engagements sit between a first product, a difficult integration, and a system that has outgrown its original plan.

Engineer reviewing an AI product workflow with human approval points from a coastal workspace in Ericeira, Portugal
Good engineering leaves important decisions, approval points, and failure paths visible.
01

AI Opportunity Audit

I map one team or workflow, rank the practical AI and process opportunities, and turn the findings into a decision-ready 30-day action plan.

The situation

You know the work is inefficient, but the right intervention is still unclear.

My role

I study the work as it happens, not as a generic AI use-case catalogue.

Common deliverables
  • Workflow findings
  • 3–7 ranked opportunities
  • Recommendation detail
  • 30-day action plan
02

AI systems

AI agents and automations built around real work, existing tools, and clear human control.

The situation

A team is repeating research, support, reporting, or follow-up by hand, and important context keeps getting lost between tools.

My role

I study the current workflow, connect the data it depends on, automate the parts that can be checked, and keep people responsible for consequential decisions.

Common deliverables
  • AI workflow design
  • Knowledge bases and retrieval
  • Integrations with the tools you already use
  • Testing, safeguards, and human approval
03

Product engineering

Full-stack product work from the first technical decision through launch and iteration.

The situation

The product makes sense in conversation, but architecture, interface, data, and delivery have not yet come together.

My role

I define the smallest version worth shipping, build the full path through the product, and make the trade-offs visible before they become expensive.

Common deliverables
  • Product definition and technical plan
  • Full-stack web applications
  • APIs, data flows, and integrations
  • Launch, analytics, and iteration
04

Technical direction

Hands-on technical leadership for products that need a decision, a recovery plan, or a difficult release.

The situation

A team can ship quickly and still move in the wrong technical direction. The cost shows up later as rewrites, brittle delivery, or stalled hiring.

My role

I work close to the product and code, challenge risky assumptions, make the next decisions explicit, and help the team deliver the difficult part.

Common deliverables
  • Architecture and delivery reviews
  • Roadmap and scope decisions
  • Technical due diligence
  • Hands-on support for critical releases
05

Search and discoverability

Technical and editorial work that makes a product easier to find, understand, and trust.

The situation

A strong product can stay invisible when its website, content, and public proof do not explain it clearly.

My role

I improve the site structure, writing, structured data, performance, and public proof, then measure whether discovery actually improves.

Common deliverables
  • Site structure and technical SEO
  • Structured data and entity clarity
  • Search-ready content models and source files
  • Measurement and visibility diagnostics
06

Technical writing & publishing

Technical articles, documentation, and reports written by someone who can follow the code and question the claims.

The situation

The expertise exists inside the team, codebase, and product history, but none of it is yet clear enough for the intended reader.

My role

I read the available material, interview the people who know the system, write the piece, resolve technical review, and prepare it for publication.

Common deliverables
  • Technical articles and explainers
  • Product and developer documentation
  • Research-backed technical reports
  • Editing, diagrams, metadata, and CMS publishing

Working together

Direct communication and early working software.

I keep decision-makers close, tackle the riskiest useful slice first, and document what the team will inherit.

01

Define the real risk

I speak with the people closest to the work and find the assumption most likely to cost time or trust.

02

Build the first useful slice

Working software arrives early enough to replace speculation with feedback.

03

Put it under pressure

I test permissions, edge cases, bad inputs, and the moments when a person needs to take control.

04

Leave it maintainable

The code, decisions, and measurements are clear enough for the team to continue without me.

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 does David Dacruz build?

David builds AI workflows, web products, and the technical foundations behind them. He can take an unclear problem from the first product decision through to working software.

Where is David Dacruz based?

David is based in Ericeira, in the Lisboa region of Portugal. He works with teams across Europe and remotely.

What kind of project is the best fit?

The strongest fit is a real product, workflow, or technical decision that needs senior judgment and hands-on delivery. The scope can start small as long as there is an owner who can make product decisions.

How does David approach an AI system?

He starts with the real work: who does what, which information is needed, and where decisions fail. AI is added only where it is dependable, with review, permissions, testing, and recovery built in.

Can David work as a hands-on technical lead?

Yes. David can frame architecture and delivery decisions while staying close to the critical code, product behavior, and release path.

Does David work on Bitcoin and Ordinals products?

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

Has David shipped Ethereum smart contracts?

Yes. For Yakuza Inc., David 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.

Send me the situation as you understand it today.

Start a conversation