Skip to content
Paulius Alionis

AI Product Engineer

I turn operational problems into working AI tools and digital products.

From the business case and the user experience through to data architecture, automation and deployment.

I am a product-minded builder with a background across business, marketing, UX, data and engineering. I own the full path from problem discovery to a working prototype or a deployed product.

Before building software full time I ran e-commerce, agency and conversational-marketing businesses. That is why I tend to recognise the workflow worth automating before I write anything, and why I use AI where it genuinely creates value rather than relabelling deterministic automation as intelligence.

Focus
Internal tools, workflow automation and end-to-end digital products
Working with
Claude, Codex, Cursor, n8n, Make and Zapier

20

therapists onboarded to a private preview

CBT Flow, owner-reported

Live

internal operating system in daily staff use

REEI OS, owner-reported

2024–25

applied AI lecturer at edON Academy

Plus talks since 2019

Selected work

Four systems, each opened up as far as the evidence honestly goes.

01 / 04Private preview

CBT Flow

A connected practice system for CBT therapists, built end to end

Therapists were running a practice across a diary, a spreadsheet, an inbox and a filing cabinet, with client care and commercial admin split between tools that never spoke to each other. CBT Flow is one connected system covering the therapist application, client portal, CRM, CMS, billing, messaging, calendars and the data foundation underneath all of it.

Open as a page

A connected practice system for CBT therapists, built end to end

Role
Sole end-to-end product owner and builder
Years
2025 — 2026
Status
Private preview
Stack
Next.js, Supabase, Postgres, Stripe, TypeScript

Therapists were running a practice across a diary, a spreadsheet, an inbox and a filing cabinet, with client care and commercial admin split between tools that never spoke to each other. CBT Flow is one connected system covering the therapist application, client portal, CRM, CMS, billing, messaging, calendars and the data foundation underneath all of it.

The problem

A small therapy practice runs on a surprising number of disconnected parts: booking, intake, consent, session notes, treatment plans, homework sent to clients, invoicing, subscription limits, marketing pages and email follow-up.

Each of those has a tool. None of them share a client record. The therapist becomes the integration layer, re-entering the same details and reconciling the same appointment across four systems while trying to deliver clinical work.

The insight

The problem was never a missing feature. It was that no single system held the client, the plan, the sessions, the money and the communications together.

Building it as one product with a shared data foundation meant the operational workflows could finally reference each other: capacity affects booking, booking affects billing, the treatment plan drives the session workspace, and the session drives what the client sees in their portal.

What I built

  • A public marketing site and CMS with structured publishing and SEO controls, so the practice's acquisition surface is part of the product rather than a separate website.
  • A CRM covering the client lifecycle from first enquiry through onboarding, with a workflow builder for email, wait, condition and tag automation.
  • The therapist application: caseload board, Treatment Plan with protocol application, and a session workspace that pulls context, plan, notes, resources and follow-up into one task-focused interface.
  • A client portal closing the loop, so assignments and progress flow back to the therapist rather than sitting in an inbox.
  • Commercial operations underneath: subscription entitlements, capacity logic, Stripe foundations, invoicing, reminders and reporting.

Key decisions

One data foundation before any feature work

Role-based access, consent evidence, eligibility controls and selected-field encryption were modelled at the start. Retrofitting permissions onto clinical data is close to a rewrite.

Restricted clinical administration

Administrative roles can operate the practice without reading clinical content. The separation is enforced in the data layer, not just hidden in the interface.

Automation kept deterministic

Scheduling, reminders, entitlements and workflow rules are ordinary software with predictable behaviour. This is a clinical context, and predictability matters more than sophistication.

Capacity as a first-class concept

Subscription tier, caseload capacity and booking availability are the same constraint expressed in three places, so they are modelled once.

Gallery

The connected system: site and CMS, CRM, application, data, billing, email and calendars

Proves: End-to-end systems thinking and connected architecture

01 / 10

Status and evidence

  • Owner-reported: 20 therapists received private-preview access, completed onboarding and began using the product.
  • CBT Flow was demonstrated live at the BABCP Annual Conference and Workshops 2026, held 14 to 16 July at the University of Warwick, Coventry.
  • Product definition, systems architecture, UX, data model, implementation, integrations, deployment configuration and documentation were all my own work.

What this does not claim

  • This is a private preview, not a fully production-ready or certified product.
  • No clinical or business outcomes are claimed, and no adoption, revenue or conversion figures are published.
  • No independent security audit or regulatory certification has been carried out.
  • AI is not a central capability of this product and is not presented as one.

cbtflow.com

02 / 04Live, in daily staff use

REEI OS

Turning marketing signals into sales actions inside one internal operating system

An energy-sector business could see its marketing activity and its sales pipeline, but never in the same place, so nobody could say which campaigns produced actual commercial demand. REEI OS connects CRM workflows, website enquiries, opportunities, marketing analytics, SEO monitoring and conversion attribution into one internal system used daily by staff.

Open as a page

Turning marketing signals into sales actions inside one internal operating system

Role
Product design, data architecture and implementation
Years
2025 — 2026
Status
Live, in daily staff use
Stack
Next.js, Postgres, Google Ads API, GA4, Search Console, DataForSEO

An energy-sector business could see its marketing activity and its sales pipeline, but never in the same place, so nobody could say which campaigns produced actual commercial demand. REEI OS connects CRM workflows, website enquiries, opportunities, marketing analytics, SEO monitoring and conversion attribution into one internal system used daily by staff.

The problem

Marketing performance lived in Google Ads, GA4 and Search Console. Commercial reality lived in a CRM that had been inherited and never fitted the business. Website enquiries arrived by email and were retyped by hand.

The question everybody wanted answered — which marketing activity produces real opportunities — required a person to manually reconcile four sources, so in practice it went unanswered.

The insight

The gap was not analytics. Each individual tool reported accurately. The gap was that no system joined a keyword or a campaign to a deal with a commercial value attached.

Once enquiry ingestion, deduplication and source tagging were automatic, attribution stopped being a reporting exercise and became a property of the record itself.

What I built

  • The inherited CRM was rebuilt around REEI's own companies, contacts, deals, stages, commercial values, tasks and BESS workflow templates.
  • WPForms enquiry ingestion runs automatically with contact and company deduplication, source tagging and conversion attribution.
  • Google Ads, GA4, Search Console, DataForSEO and WPForms are connected through APIs, OAuth, encrypted credentials and webhooks.
  • Page Performance, Keyword Discovery and Conversion Chain views join marketing activity to business demand in a single interface.
  • Integration health, synchronisation logs, API usage, cost controls, tenant boundaries and exports keep the thing operable rather than merely impressive.

Key decisions

Decision support, not a black box

Opportunity scoring and recommendations are deterministic rules. Staff can see exactly why something was surfaced, which is why they trust it enough to act on it.

Adapt a foundation rather than start from zero

The application shell, tenancy, monitoring and parts of the analytics foundation came from an earlier product of mine and were then substantially reworked for this domain.

Attribution written at ingestion

Source and campaign data are attached when the enquiry is created, not reconstructed in a report later, which is what makes the conversion chain reliable.

Paid API cost control from day one

Ranking data costs money per query, so frequency awareness and usage caps were built in before the bill could become an argument.

Gallery

Executive dashboard: traffic, demand, pipeline and search in one view

Proves: Cross-functional operational visibility

01 / 08

Status and evidence

  • Owner-reported: live at an internal address and used by REEI staff for marketing-performance monitoring, SEO position tracking and managing sales and lead status.
  • Integrations with WPForms, Google Ads, GA4, Search Console and DataForSEO are connected to live data.

What this does not claim

  • REEI OS is not AI-powered. Its scoring and recommendations are deterministic decision support, and describing them as AI would be inaccurate.
  • The application shell, tenancy, monitoring and parts of the analytics foundation were inherited from an earlier product of mine and then substantially adapted. RankPass was later forked from this work, so the two are related rather than independent builds.
  • Live operational use and deployment are owner-confirmed. Measurable business results are not claimed.
  • The internal application is not linked publicly.

reei.lt

03 / 04Deployed MVP in user testing

RankPass

A multi-tenant SEO monitoring SaaS with the commercial machinery attached

Ranking data is cheap to display and expensive to collect, which is what makes SEO monitoring a genuine product problem rather than a dashboard exercise. RankPass combines scheduled collection, ranking analytics, Google data pipelines, subscriptions, cost controls, customer dashboards and an operator console in one connected system.

Open as a page

A multi-tenant SEO monitoring SaaS with the commercial machinery attached

Role
Product definition, UX, data architecture and build
Years
2026
Status
Deployed MVP in user testing
Stack
Next.js, Postgres, DataForSEO, Stripe, OAuth

Ranking data is cheap to display and expensive to collect, which is what makes SEO monitoring a genuine product problem rather than a dashboard exercise. RankPass combines scheduled collection, ranking analytics, Google data pipelines, subscriptions, cost controls, customer dashboards and an operator console in one connected system.

The problem

Monitoring rankings at any scale means paying per query to an external data provider on a schedule, for many keywords, across many customers.

That turns an apparently simple product into a cost-control problem: without frequency awareness and usage limits, the margin disappears quietly and only shows up on the invoice.

The insight

The interesting engineering is not the chart. It is the scheduling, the tenancy and the spend controls that make the chart affordable to produce.

Building the operator console alongside the customer product meant the commercial model was visible during development rather than discovered afterwards.

What I built

  • Frequency-aware scheduled workflows collect ranking data on a per-plan cadence with explicit paid-API cost controls.
  • External integrations, OAuth foundations, signed payment webhooks and lifecycle email are wired into a multi-tenant data model with isolation between customers.
  • Customer dashboards cover keyword management, rankings history and multi-domain management.
  • An operator console exposes plans, usage costs, subscriptions and system health on the same data.

Key decisions

Cost per tenant treated as a product constraint

Collection frequency is bound to plan level, so the unit economics are enforced by the system rather than by hoping customers behave.

Operator console built in parallel

Running a SaaS needs a view of plans, spend and health. Building it alongside the customer product kept the commercial model honest.

Forked deliberately from an existing foundation

RankPass was forked from REEI OS. Reusing the tenancy, monitoring and analytics groundwork was a deliberate choice, not a coincidence of two similar products.

Gallery

Customer dashboard

Proves: Productised reporting experience

01 / 06

Status and evidence

  • Deployed and in user testing.
  • Product definition, UX, data architecture, the SaaS commercial model and deployment design were my own work.

What this does not claim

  • RankPass has no language-model or AI functionality. It is automation, analytics, API integration and product engineering, and calling it AI would be inaccurate.
  • No users, revenue, ranking accuracy or customer outcomes are claimed.
  • It is an MVP in testing rather than a commercially finished product, and not every advertised plan feature is fully enforced yet.

rankpass.app

04 / 04Built systems in use, plus a concept prototype

DiamondLine

Operational automation for an omnichannel beauty business, plus a concept prototype

A professional beauty-products business selling through a WooCommerce storefront, a physical shop and sales managers, with the order and customer picture split across all three. Two distinct pieces of work sit here: automation that is built and running, and a separate business-management prototype that is explicitly a concept.

Open as a page

Operational automation for an omnichannel beauty business, plus a concept prototype

Role
Automation build and product concept design
Years
2023 — 2026
Status
Built systems in use, plus a concept prototype
Stack
WooCommerce, Automation tooling, Prototype

A professional beauty-products business selling through a WooCommerce storefront, a physical shop and sales managers, with the order and customer picture split across all three. Two distinct pieces of work sit here: automation that is built and running, and a separate business-management prototype that is explicitly a concept.

The problem

Selling through a website, a shop counter and a team of sales managers means three different order intakes, three views of the customer and one accounting process expected to absorb all of it.

Loyalty and repeat purchasing are where the margin lives in this category, but they are impossible to run well when the customer record depends on which channel the person happened to buy through.

The insight

The accounting workload was a symptom rather than the problem. The real cost was that no single place described a customer or an order across the channels.

That distinction is why the work splits in two: automating what already existed and could be measured, and prototyping the unified system separately rather than pretending it was built.

What I built

  • Built and operating: accounting operations automation, removing repetitive manual reconciliation from the finance workflow.
  • Built and operating: a loyalty programme for customer retention across the business.
  • Concept prototype, clearly labelled and not deployed: an omnichannel operations system covering unified order intake, customer and loyalty profiles, fulfilment, products and stock, sales-manager workflows, marketing segmentation and commercial reporting.

Key decisions

Ship the automation, prototype the platform

The accounting and loyalty work was deliverable immediately and paid for itself. The unified operations system was a much larger commitment, so it was explored as a concept first.

Keep the two clearly separated

Presenting a prototype as a running system is the fastest way to lose credibility. The distinction is labelled everywhere it appears, including on the screenshots.

Gallery

The public storefront and commerce context

Proves: A real omnichannel business context

01 / 06

Status and evidence

  • The loyalty programme and accounting automation are built and in use by the business.
  • The omnichannel operations system is a design and prototype exercise, labelled as a concept throughout.

What this does not claim

  • The business-management system is a concept prototype. It is not deployed, not in use and produces no business results.
  • Only the loyalty programme and accounting automation should be read as delivered work.

diamondline.lt

How I build

The same eight steps whether it is one dashboard or a whole product.

01

Discovery

Sit with the people doing the work and map what actually happens, including the spreadsheet nobody mentions in the process diagram.

02

Business case

Establish what the change is worth before designing it. If the numbers do not hold up, the honest answer is to not build it.

03

Experience

Design the operational interface around the task, not the database. Fewer screens, less training, fewer support questions later.

04

Data architecture

Model the entities and permissions early. Access control, tenancy and audit trails are much cheaper before the first release than after it.

05

Automation

Automate the deterministic parts deterministically. Reach for models where language, ambiguity or judgement is genuinely involved.

06

Deployment

Ship it somewhere real, with environments, secrets handling, backups and monitoring rather than a demo that only runs locally.

07

Measurement

Instrument the workflow so the effect is observable, and separate what is implemented from what is proven.

08

Iteration

Watch it in use, remove what nobody touches, and deepen what people rely on.

Experience

The business years are why I can spot the workflow worth building.

  1. 2024 — present

    Independent Product Engineer & Digital Consultant

    Self-employed

    Designing and building internal tools, operational dashboards, automations and full products for businesses that need software shaped around how they actually work.

  2. 2024 — 2025

    AI Lecturer

    edON Academy

    Teaching applied AI to working professionals: what current tools can genuinely do, where they fail, and how to put them into a real workflow.

  3. 2021 — 2024

    Freelance Web Developer & Digital Marketer

    Digita1 Agency

    Websites, e-commerce builds, marketing infrastructure and automation for clients across several sectors.

  4. 2018 — 2024

    Co-founder, CEO & Lead Strategist

    ChatMarketing

    Chatbots, conversational commerce, and sales and customer-service automation. Work delivered for BC Žalgiris, BIGBOX, INVL, Technorama, Flokati, Lithuanian Post and Trobos.

  5. 2017 — 2018

    Digital Director

    BeautyClick, Kenya

    Digital marketing leadership, creative direction, team building, influencer and partner relationships, and paid advertising.

  6. 2014 — 2019

    Founder & CEO

    GentleHair

    Five years of e-commerce operations, delivery to more than 100 countries and international wholesale distribution, with an audience of roughly 20,000 on Facebook, 12,000 on Instagram and 18,000 on YouTube.

Teaching and domain expertise

I teach applied AI to professionals who have to make it work on Monday morning, which keeps me honest about the difference between a demo and a dependable tool.

  • AI lecturer at edON Academy, 2024 to 2025.
  • Speaking and knowledge sharing at KTU, VDU, Kauno Kolegija, LIMA and other organisations since 2019.
  • Day-to-day work with Claude, Codex, Cursor, n8n, Make and Zapier.