Practical websites, automation, and AI workflow notes

I turn messy ideas into working web systems.

I'm David Ortiz. I build practical sites, workflow prototypes, and clear handoff notes for projects where the real value is getting the system working and understandable.

Desk scene with a laptop, notebook, and project cards representing a builder's workbench.
How this page should readPersonal, useful, and specific.

No inflated claims. No agency wrapper. Just what I build, how I work, and how to reach me.

Current lanes
Local sitesforms, copy, deploys
AI workflowresearch to QA
Automationsmall, documented systems

A portfolio for the work I actually do.

This site is the front door for selected builds, current learning, and practical collaboration. Outside projects can show up as examples, but the organizing idea is simple: David Ortiz, the work, and a direct path to contact.

  • DeKalb, IL and remote
  • Screened contact path
  • English or Spanish
  • Built with Next.js on Vercel

Five lanes I keep returning to.

These are portfolio categories, not inflated case studies. Each one points to the kind of systems I can build, test, and explain clearly.

Web

Local Business Sites

Focused websites for small businesses: clear services, simple contact paths, bilingual-friendly copy, DNS/deploy setup, and handoff notes an owner can use.

  • Next.js
  • Forms
  • Local SEO
  • Handoff
See live demos (pedidos, citas, servicios)
Systems

AI-Assisted Workflows

Practical workflows that split research, implementation, review, QA, and documentation into visible steps instead of hiding everything inside one prompt.

  • Codex
  • Claude
  • Browser QA
  • Runbooks
Knowledge

RAG and Notes Tools

Experiments around retrieval, cited answers, local notes, and the habit of checking the actual source before treating a generated answer as true.

  • RAG
  • Search
  • Citations
  • Obsidian
Ops

Automation and Cleanup

Small automations for intake, follow-up, project cleanup, and deployment checks, with the maintenance path documented before the work is considered done.

  • n8n
  • APIs
  • Scripts
  • QA
Safety

Prompt Safety Learning

Ongoing study of AI guardrails, prompt injection, misuse boundaries, and the practical checks needed before an AI-powered workflow should be trusted.

  • Guardrails
  • Testing
  • Scope
  • Review

How I keep projects grounded.

The common thread is verification. I would rather inspect the actual surface and make a smaller honest improvement than write a big plan that never reaches the browser.

01

Start With The Real Surface

I look at the repo, browser, files, deployment, or workflow first so the work starts from evidence instead of labels.

02

Map The Useful Version

I separate facts, assumptions, and open questions, then turn the mess into a small buildable scope.

03

Build In Working Passes

I prefer a working first version, then tighten copy, layout, routes, contact paths, and edge cases from there.

04

Verify And Hand Off

I run the checks that matter, document what changed, and leave the next person with a clear continuation path.

Tools I reach for when the job fits.

The stack changes by project, but the goal stays the same: ship something understandable, verify it, and leave the maintenance path visible.

Frontend

  • Next.js
  • React
  • Tailwind CSS
  • Accessible UI

Deployment

  • Vercel
  • Netlify
  • DNS setup
  • Production QA

Automation

  • n8n
  • APIs
  • Shell scripts
  • Operational notes

AI Workflow

  • Codex
  • Claude Code
  • Grok
  • Perplexity
  • Obsidian

What I'm paying attention to right now.

This is the living part of the portfolio: fewer broad claims, more notes about what is being built, tested, and tightened.

  • Cleaner local-business websites with quote, order, or contact flows that do not feel overbuilt.
  • Repeatable AI-assisted delivery: research, implementation, review, browser QA, and a written handoff.
  • Security-aware AI workflow habits, especially prompt injection, tool boundaries, and validation.
  • Better notes that preserve what worked, what failed, and what should happen in the next session.

Send the rough version.

You do not need a polished brief. Send the project, the problem, the current link or file if you have one, and what would make the next step useful. I keep the public contact path screened so the phone number is not treated like an open spam target.

Best first message

What are you trying to build or fix, and what is the current state?

Phone spam guard
  • Public links start with project context instead of a bare phone number.
  • A future WhatsApp/n8n screener can label spam, ask one clarifying question, and keep human approval on replies.
  • Direct calls should happen after context, not as the first public CTA bots can scrape.