Fintech · SaaS · SEO

FactuPlanElectronic-invoicing platform for Ecuador's SRI

Multi-tenant SaaS platform for electronic invoicing against Ecuador's tax authority (SRI). I worked on the product frontend and on the whole site that sells it: blog, SEO structure, measurement in Google Analytics and Search Console, and the funnel that turns visits into customers.

Technologies

  • Next.js
  • TypeScript
  • Refine
  • NestJS
  • GraphQL
  • PostgreSQL
  • Clerk
  • AWS S3
  • Google Analytics 4
  • Search Console
  • JSON-LD
  • Technical SEO
  • UX/UI
FactuPlan interface, an electronic-invoicing platform for Ecuador's SRI

My role

Web & applications developer at Azirgo SAS. I worked on the panel frontend and, above all, on the public site: content and blog, SEO structure, UX/UI, measurement with Google Analytics and Search Console, and analysis of the acquisition funnel.

The problem

The hard part of an invoicing SaaS is not only issuing documents the SRI will accept: it is getting the businesses that need to invoice to the platform in the first place. The product already matched the spec, but the site brought in no search traffic of its own, there was no way to tell which pages earned impressions and clicks, and no way to separate a curious visitor from a business that would actually sign up.

What I built

  • Frontend of the public site: product, plans, pricing and contact pages, with UX/UI aimed at reaching signup.
  • An in-house blog on electronic invoicing, SRI obligations and taxpayer questions, as the organic entry point.
  • The site's SEO structure: a page hierarchy by search intent, titles and descriptions, internal linking, sitemap and structured data.
  • Measurement in Google Analytics 4 with custom events for every funnel step: visit, signup, plan selected and contact.
  • Search Console tracking of clicks, impressions, CTR and position per query, to decide which content to expand, rewrite or merge.
  • Frontend of the multi-tenant SaaS admin panel, with each company isolated inside the same platform.
  • Microservices for generating the invoice PDFs, plus taxpayer lookup to validate details before issuing.
  • A GraphQL API as the single data layer behind the panel, with documents stored on AWS S3.

Technical decisions

  • Treat the site as part of the product rather than a brochure: every page exists to answer one real search and end in a signup.
  • The blog goes after the taxpayer's actual questions (deadlines, document types, SRI rejection errors), because whoever searches for those is exactly who needs to invoice.
  • Custom GA4 events instead of settling for pageviews: without one event per step you cannot see where the funnel drops.
  • Search Console as the source of truth for demand: look first at which queries already earn impressions, then write the content.
  • Next.js with server rendering so the blog and the commercial pages are crawlable from the first deploy.
  • PDF generation lives in its own microservice so a burst of invoices never blocks the main API.

Challenges

  • Qualifying leads with what can actually be measured: telling an informational visit apart from a business that will sign up.
  • Letting educational content and commercial pages coexist without cannibalising each other on the same searches.
  • Keeping measurement consistent between the public site and the product, so the full funnel can be read end to end.
  • The SRI document format leaves no room for approximation: the document either matches the spec or it is rejected.

Result

The platform is in production, with different companies issuing their invoices from the same panel, and the site works as its acquisition channel: blog and intent pages published and crawlable, the funnel instrumented in GA4, and per-query performance tracked in Search Console to decide what to write next.

See it live

Need something like this?

Tell me what you're building and I'll come back with scope, stack and a realistic timeline.