Skip to content / Saltar al contenido
SHIP/001

PGAS: a service I designed as a product

SEO, AEO and GEO as one method — so a business shows up on Google and gets cited by ChatGPT and AI Overviews.

Type
SEO · AEO · GEO
Year
2026
Role
Founder / Product Engineer
Stack
Next.js · TypeScript · JSON-LD · Vercel
Status
Live
pgas.online homepage: SEO, AEO and GEO consultancy
(opens in a new tab)

By Published

Summary

I shipped PGAS as SKUs, not as a sales call. VERA turns search visibility and model citations into fixed deliverables, deadlines, and prices in Chilean pesos. The live site at pgas.online is the proof: JSON-LD, questions written as H2s, and a lead a model can quote. I designed it — Jorge Cortés — as a product engineer.

Problem

Demand moved. People ask ChatGPT, read Perplexity, and stop inside Google AI Overviews. The work most agencies sell did not move with them.

The default offer is still five-year-old SEO. Keywords. A monthly PDF. Price behind “request a quote”. Scope negotiated on a call. The method is a slide deck. The agency site does not demonstrate the pages it claims it can build for a client.

That is a product failure, not a copy failure. Liquid scope cannot carry a public number. A method that only exists in a meeting cannot be versioned. A landing page is not evidence that you know how to build something a crawler and a language model can use.

I did not want another agency. I wanted a service with a catalog, a pipeline I can run, and a site that is the demonstration of that pipeline. SEO, AEO, and GEO are what the product sells. They are not the territory of this case. This page is about how I packaged the work.

Constraints

I built it alone, as founder and product engineer. 2026. Santiago, Chile. Billing is in CLP — LATAM too, with boleta or factura. Monthly plans have no minimum stay. Those rules cut the cost of starting and force every SKU to fit a number I can publish.

There is no CMS and no database behind the site. The declared stack is Next.js, TypeScript, JSON-LD, and Vercel. Inventing a dashboard or Supabase would be a lie. Copy lives in the repo. Each URL is an artifact I control, the same way I control this domain.

Second constraint: the graph. jorgeco.tech is the canonical source on the entity Jorge Cortés. PGAS is a product that entity built. SEO, AEO, and GEO copy cannot live on both domains. If this site ships posts on “how to show up in ChatGPT”, it cannibalizes the agency and muddies the person. The method is explained on the product. This case only covers how I built it.

Third: catalog honesty. A public price is a promise. To publish one I froze deliverables. Fifteen on-page URLs. Four pieces of content a month. A diagnostic in 48 hours. If a client wants more, it is not “we’ll see”. It is a change order. Custom work exists, but it sits at the bottom of the catalog as the exception, not the default.

Fourth: extractability. Key pages have to be citable: a 50–80 word lead, questions as H2s, JSON-LD that matches the HTML. A lead that answers the question can sound like a spec sheet. A body that only does brand voice does not get cited. Both layers have to live in the same template.

That whole set is product engineering: turning an opaque service into a system with a catalog, artifacts, and a site that demonstrates the method.

Architecture I designed

VERA is not a homepage acronym. It is the delivery pipeline. Each letter has a window, artifacts, schema types when they apply, and a KPI. The PGAS site itself implements Response and Understanding. Visibility and Authority run on the client’s domain. PGAS marketing is not the job. It is the test bench.

Visibility — weeks 1 and 2

Artifacts: technical audit, indexation checklist, on-page work on a closed set of URLs, Search Console and GA4, a Core Web Vitals budget, crawl control. KPI: impressions and top 10.

On PGAS, Visibility is also information architecture. The public nav is Services, VERA method, Prices, About, Blog, and Contact, plus service pages (SEO, AEO, GEO, web development). It is a growing engine. I am not going to invent an indexable URL count.

Understanding — weeks 2 and 3

Artifacts: one JSON-LD graph per page. Organization, Service, FAQPage, HowTo, Speakable, Article, plus entity reinforcement (name, brand, founder–product link). KPI: valid schema and rich results. If the markup does not match the HTML, the type does not count.

The PGAS site is the example. Questions are H2s, not a hidden accordion. The method page opens with an executive summary block. Markup follows what is on screen. Same pattern as this domain: one graph per page, stable @id values, App Router. Not a plugin. Code.

Response — weeks 3 and 4

Artifacts: Q&A templates a model can extract, a 50–80 word lead at the top of key pages, PAA and snippet coverage, a mention loop every two weeks. KPI: snippets plus model citations. The loop is still partly manual. The method says so: fortnightly tracking by hand. That is a product gap.

Authority — from month 2

Artifacts: off-site mentions, original data worth citing, directories models actually read, AI Overviews tracking. KPI: Overviews plus referring domains. This phase does not fit a two-week one-shot. That is why the catalog splits implementation (technical SEO, AEO+GEO, web pack) from monthly retainers. Authority is a loop, not a launch SKU.

The four-node diagram is build order. Authority is not requested if Visibility is not indexing. Understanding is not marked up if the HTML cannot carry the types.

Stack and why

Next.js because the site is the product and the product is pages. App Router, one route per artifact, metadata per page, the same pattern as jorgeco.tech.

TypeScript because the catalog, the schema types, and the routes are contracts. A wrong price in a PDF is another PDF. A wrong price in code fails a build. The Web+SEO+AEO pack on the catalog names Next.js, schema preloaded, and a Vercel deploy. The stack I sell in that SKU is the stack PGAS is built with.

JSON-LD by hand, in each page’s graph, because AEO and GEO are the work. If markup comes from an opaque plugin, I cannot version it or check it against the HTML. The types the method names have to be reviewable code.

Vercel because the loop is Think / Build / Ship. Preview per branch, production, no server I administer.

No Supabase. No CMS. The engine grows in the repo. That limits who can edit copy. In exchange, every URL is a commit. For a site that has to be citable, I prefer that friction.

Technical decisions

The decision that orders the rest: the catalog is the product. /precios has an H1 that names SEO, AEO, and GEO in Chilean pesos. Diagnóstico Express is published at $79.000 CLP in 48 hours: a PDF, a 30-minute call, and the top five opportunities across Google, ChatGPT, Perplexity, and Gemini. That SKU exists so someone can buy a first cut without a sales meeting.

The other one-shots freeze timeline and deliverable the same way. Custom work sits at the bottom. A quote is overflow, not the default.

Monthly plans (Esencial, Visibilidad, Crecimiento) do not ask for a lock-in. I can change a promo in one place because price is data, not a PDF. The day I captured the site, the first ten diagnostics were free. That is not the product. It is proof the offer is edited where the catalog lives.

The diagnostic is credited in full if you hire implementation within 30 days. I mention that once, as offer engineering: it lowers the cost of trying the entry SKU. It is not a coupon. It is a pricing rule.

Second decision: two domains, two jobs. The product talks about the method and sells the service. This domain talks about who built it. The PGAS footer reads “Creada por Jorge Cortés” and links the founder. This page closes the other direction without cloning the agency blog.

Third: extractability as a template. The 50–80 word lead answers the page’s question. The body keeps the voice. FAQs are H2s. A model summarizing the page gets a short block at the top and questions that look like questions. That is Response in the markup.

Fourth: one graph per page. I inferred the same pattern I use here. Types the HTML can support. No Speakable on a paragraph you would not read aloud. No FAQPage if the questions are not in the document. Schema drift is a release failure.

Fifth: the site as a lab. Each new template is an extractability experiment. The engine grows because the method needs surface, not because a blog has to ship on a calendar.

What went wrong

The first problem was content architecture. If I explain VERA in depth here, this domain becomes a second SEO blog. If I explain nothing, the case does not show engineering.

The second is the catalog trade-off. Agencies hide price because scope varies. If I freeze fifteen pages, four contents, and 48 hours, the public number is honest. If a client shows up with 80 URLs and three languages, the SKU no longer fits. The natural pressure is to stretch the deliverable and keep the price. That rots the catalog. The real bug is having no change-order path.

The third is voice. A lead written to be cited can read like a spec. Question-shaped H2s can read like a support FAQ. If I put voice in the lead, the model cites a paragraph that answers nothing. If I drop extractability in the body, the site reads like a manual.

The fourth is schema drift. HowTo, Speakable, FAQPage, and Article are easy to invalidate. You change an H2, leave the old JSON, and the type lies. Without a release gate, the graph rots quietly.

The fifth is citation measurement. The method asks for fortnightly mention tracking in ChatGPT and Perplexity. Today that is, in part, a person prompting a model and taking notes. It does not scale. It is the most honest gap in the product.

How I fixed it

  1. 01/
    I split the graph across two domains. SEO, AEO, and GEO live on the product. This domain only publishes the builder case. The Jorge Cortés profile links the product; the product links the founder. Nobody duplicates posts.
  2. 02/
    I froze deliverables per SKU. Fifteen pages, four contents, 48 hours. Extra work is a change order, not a fuzzy quote. Custom work became the overflow SKU at the foot of the catalog.
  3. 03/
    I split lead and body in the template. The 50–80 word block answers. The rest holds the voice. Visible questions are H2s, aligned with FAQPage.
  4. 04/
    I treated schema as a release contract. HTML wins. JSON-LD copies. If I cannot validate the type, I do not ship it. Automation of that gate is not closed yet.
  5. 05/
    I left citation tracking as a manual loop and marked it as debt. I did not sell a dashboard that does not exist. The method says “fortnightly” and “manual”. The product has to grow toward a structured log.

Crediting the diagnostic at 30 days and skipping a minimum stay both lower the cost of entering the system without diluting the SKU. The public price holds because scope is closed.

Result

PGAS is live. The public catalog bills in CLP. The entry diagnostic ships in 48 hours. VERA has four phases and a KPI each. That is all I can claim without inventing clients, rankings, traffic, or revenue.

Published diagnostic
48 h
Prices in the open
CLP
VERA phases with a KPI
4
Status
Live

The product result that matters is structural. A service that used to be a quote now reads as a catalog. A method that used to be a talk is a pipeline with artifacts. An agency site is now the demonstration of Response and Understanding. Diagnóstico Express at $79.000 CLP makes that thesis observable: you can buy a cut in 48 hours without asking for a proposal.

No clients or rankings on the record.

Evidence

pgas.online homepage: SEO, AEO and GEO consultancy with the VERA method
Fig. 01 — PGAS home on 2 September 2026. Nav for services, method, prices, and blog. Not a quote landing.
PGAS pricing page in Chilean pesos, with one-shot and monthly catalog
Fig. 02 — /precios on 2 September 2026. The H1 names SEO, AEO, and GEO in Chilean pesos. A quote sits as the exception.
VERA method page: Visibility, Understanding, Response, and Authority
Fig. 03 — /metodo-vera on 2 September 2026. Four phases with window, artifacts, and KPI. The executive summary at the top is Response in the template.

Live product: pgas.online. One outbound link. The footer credits Jorge Cortés. This case documents how I packaged it.

What I'd do differently

Citation tracking cannot stay as a fortnightly round in someone’s head. What I would build now is a structured log: date, model, prompt, cited or not, URL cited, snapshot. A schema’d sheet, not an oral count. If that tool already exists in the operation, this paragraph is leftover.

Schema drift: I would not leave it to a manual pass. I would make it a release gate. Rich Results Test or a CI validator on routes that declare FAQPage, HowTo, and Speakable. I inferred that gate because the graph requires it. I am not claiming it runs today.

Lead length should be a template field. 50–80 words is the rule the method names. I want it locked on every page type, with a build check.

I would count indexable URLs and publish that as an engine metric. I do not, because I do not have a closed number.

I would keep the domain split. I would not write an SEO blog on jorgeco.tech even if it ranked. If anything were shared, it would be an entity-facts module, not the method posts.

I would keep the catalog public. I would change the overflow: a small configurator for the custom SKU (pages, languages, timeline) that emits a range, not an opaque quote. Overflow would still be overflow.

Back to projects