--- title: "Drasyo services" canonical: "https://drasyo.com/services" description: "AI visibility, answer-engine optimisation, automation and website builds — what Drasyo does, what you get, and how the work runs." count: 6 --- # Drasyo services Sold separately and built to work together. Visibility without follow-through wastes the traffic; automation without visibility has nothing to process. ## AI visibility AI visibility is being findable on all three surfaces discovery now runs on: classic search results, answer boxes that quote a source, and generative assistants that cite one. Each rewards different signals, and a page built only for the first is invisible on the other two. URL: https://drasyo.com/services/ai-visibility Updated: 2026-08-04 ### What is included - Technical audit: what engines can actually read today - Intent-mapped page architecture and internal linking - Question-shaped content with extractable answer blocks - Structured data: Organization, Service, FAQPage, LocalBusiness - Entity consistency across the site and linked profiles - Monthly citation and query reporting ### How the work runs 1. **Audit** — We establish what is crawlable, what is citable, and which demand you are currently absent from. 2. **Structure** — Architecture and schema first, because content on a page an engine cannot parse is wasted work. 3. **Write** — Answer-first pages: the short version at the top, the depth underneath. 4. **Compound** — Monthly review of what got cited and what got asked, feeding the next month's writing. ### Questions **What is the difference between SEO, AEO and GEO?** SEO earns a position in a list of results. AEO earns the quoted paragraph in an answer box. GEO earns a citation inside a generative assistant's reply. They share foundations — crawlable HTML, clear structure — but differ in what they reward: SEO favours authority and relevance, AEO favours short self-contained answers, GEO favours parseable text and unambiguous entity signals. **How long before AI visibility work shows results?** Technical fixes can change how a site is parsed within days of a recrawl. Content and citation gains are slower and usually become visible across two to three months, because engines need to see the pattern repeat before they treat you as a reliable source for a topic. **Do we have to let AI crawlers access the site?** You can block them, but it forfeits citation. If a model cannot read your pages it cannot mention you, and the traffic goes to a competitor who allowed access. For most businesses selling a service, being quoted is worth more than withholding the text. --- ## Automation Automation here means the path an enquiry takes after it arrives: captured in one place, qualified by an agent asking what you would ask, routed to the right person with context attached, and followed up on a schedule rather than from memory. URL: https://drasyo.com/services/automation Updated: 2026-08-04 ### What is included - Single intake surface for forms, calls and messages - Qualifying agent with your questions and your tone - Routing by service, language and availability - Sequenced follow-up and stall detection - CRM integration, writing to the record you already use - Handover documentation so the system is not a black box ### How the work runs 1. **Map** — We trace what happens to an enquiry today, including the parts that depend on one person noticing. 2. **Wire** — Capture and routing first — the highest-value fix is usually just nothing being dropped. 3. **Qualify** — The agent goes in once routing is reliable, so its output lands somewhere useful. 4. **Tune** — Real enquiries expose the edge cases. We adjust against actual traffic, not hypotheticals. ### Built with - **TypeScript** (Interface) — One language from the database call to the button, with the types checked at the boundary between them. - **Node.js** (Application) — The runtime everything else assumes, and the same language the interface is written in. - **Python** (Application) — For the data and model work where its libraries are simply better than the alternatives. - **n8n** (Agents and workflows) — Workflow orchestration you can read as a diagram, self-hosted where the data should not leave. - **Claude and GPT APIs** (Agents and workflows) — Model calls for classification, drafting and qualification, always behind our own validation. - **Vector search** (Agents and workflows) — Retrieval over your own documents, so an agent answers from your content instead of its training data. ### Questions **Will an AI agent talk to our clients without oversight?** Only where you want it to. The default is an agent that gathers information and drafts, with a person approving anything client-facing. Fully autonomous replies are possible for narrow, low-risk cases such as confirming an appointment, and we recommend earning that scope gradually rather than starting there. **Does this replace our CRM?** No. It writes into whatever you already use. Replacing a CRM is a migration project with its own risks, and the value here comes from the enquiry arriving in your existing system already qualified and routed — not from changing where your team works. **What happens when the automation gets something wrong?** It escalates rather than guessing. Anything the agent cannot classify confidently goes to a person with the full thread attached, and the failure is logged so the rule can be fixed. A system that fails loudly is worth more than one that fails silently and confidently. --- ## Websites A Drasyo build is static-first: pages are generated ahead of time and served as HTML, so they load fast, work without JavaScript, and give crawlers and answer engines something to read on the first request rather than after a fetch. URL: https://drasyo.com/services/websites Updated: 2026-08-04 ### What is included - Design and build, mobile-first - Static generation with server-rendered HTML on every route - Core Web Vitals treated as a release gate - WCAG AA contrast, keyboard navigation, visible focus - Structured data on every template - Editable content in files your team can change ### How the work runs 1. **Define** — Which pages exist, what each one is for, and which query it should answer. 2. **Design** — Type, colour and layout resolved before a line of production code. 3. **Build** — Static routes, real HTML, motion added last and always optional. 4. **Verify** — Speed, contrast, keyboard access and structured data checked as gates, not hopes. ### Built with - **TypeScript** (Interface) — One language from the database call to the button, with the types checked at the boundary between them. - **Astro** (Interface) — Ships HTML by default and JavaScript only where a component asks for it. This site is built with it. - **GitHub Actions** (Delivery) — Tests, type checks and the performance and accessibility gates run on every push, not before a launch. - **Cloudflare** (Delivery) — Edge caching, DNS and protection in front of everything we host. ### Questions **Why static instead of a CMS-driven site?** Static pages are faster, cheaper to host, harder to break, and cannot fail to render because a database was slow. Content still lives in editable files with validated fields, so publishing does not require a developer — it just does not require a server at request time either. **Can the site still have heavy animation?** Yes, and it should be optional. On our own site every headline, paragraph and link is plain HTML that renders with the motion layer switched off entirely. Animation is added on top, gated on device capability and disabled for anyone who has asked for reduced motion. **What does 'Core Web Vitals as a gate' mean in practice?** It means a build does not ship if it regresses the metrics, rather than the metrics being measured after launch and noted as future work. In practice the biggest wins are self-hosted subset fonts, images with explicit dimensions, and not blocking first paint on anything decorative. --- ## Application development Application development is everything past a brochure site: signed-in accounts, a database that models how the business actually works, integrations with the tools your team already runs, and an interface people use daily rather than visit once. Built as a typed codebase with tests and a deploy pipeline. URL: https://drasyo.com/services/application-development Updated: 2026-09-12 ### What is included - Data and permissions modelled before the build starts - TypeScript end to end, one language across client and server - Accounts, roles and audit trail - Integrations with the systems you already run - Automated tests and a deploy pipeline on every change - Repository, documentation and access handed over ### How the work runs 1. **Model** — What the application stores, who may see it, and which decisions it is allowed to make on its own. 2. **Prototype** — The two or three screens the work actually happens on, clickable, before the rest is built around them. 3. **Build** — Vertical slices — one complete feature at a time, deployed and usable, rather than a big reveal at the end. 4. **Harden** — Permissions, failure states, backups and load. The unglamorous half that decides whether it survives contact. ### Built with - **TypeScript** (Interface) — One language from the database call to the button, with the types checked at the boundary between them. - **React** (Interface) — For interfaces with state worth managing — anything signed in, live or multi-step. - **Tailwind CSS** (Interface) — A spacing and colour scale that holds across a large application without a stylesheet nobody dares delete from. - **Next.js** (Application) — Server rendering, routing and server-side data access in one framework, so permissions are checked on the server. - **Node.js** (Application) — The runtime everything else assumes, and the same language the interface is written in. - **PostgreSQL** (Data) — Relational, boring and correct. Tenant isolation and constraints belong here rather than in application code. - **Prisma** (Data) — Schema as a file in the repository, with migrations reviewed like any other change. - **GitHub Actions** (Delivery) — Tests, type checks and the performance and accessibility gates run on every push, not before a launch. - **Playwright** (Delivery) — The handful of journeys that must never break — sign-up, checkout, enquiry — tested in a real browser. - **Docker** (Delivery) — The same environment locally and in production, so "it works on my machine" stops being a category of bug. - **Cloudflare** (Delivery) — Edge caching, DNS and protection in front of everything we host. ### Questions **How is this different from the website service?** A website is read: pages are generated ahead of time and served as HTML. An application is used: it has accounts, stores what people do, enforces who may do it, and changes state. The two are built with different trade-offs, which is why they are quoted separately even when they ship as one product. **Do you build mobile apps as well?** We build for the browser first, because one codebase covers every device and nothing waits on an app-store review. Where a native app is genuinely required — offline use, push, camera or hardware access — it is built from the same TypeScript codebase rather than as a second product to maintain. **Who owns the code?** You do. The repository is yours from the first commit, hosted in your organisation, with our access removable at any time. Handover includes the deploy pipeline, the environment variables and a written account of how the parts fit together, so another developer can pick it up without calling us. **Can you take over an application someone else built?** Often, yes. We start with a short read of the codebase and report honestly on what is worth keeping, what needs replacing and what it would cost either way. A rewrite is sometimes the right answer and is never the automatic one. --- ## SaaS product building SaaS product building is an application plus everything that makes it a business: separate tenants that cannot see each other, subscription billing and trials, self-serve sign-up and onboarding, and the usage metrics that tell you which parts are used and which were a guess. Shipped as a first version, then iterated against real accounts. URL: https://drasyo.com/services/saas-product-building Updated: 2026-09-12 ### What is included - Multi-tenant architecture with isolation by default - Subscription billing, trials, upgrades and dunning - Self-serve sign-up, onboarding and invitations - Product analytics on the paths that decide retention - Admin tooling so support does not need a developer - Release pipeline built for weekly change, not annual ### How the work runs 1. **Narrow** — One job the product does better than the spreadsheet it replaces. Everything else waits for evidence. 2. **First version** — The smallest thing a real account can sign up for and use, with billing wired from day one. 3. **Instrument** — Activation, usage and churn measured where they happen, so the next decision has something behind it. 4. **Iterate** — Weekly releases against what accounts actually do, with the roadmap re-cut when the data disagrees with it. ### Built with - **TypeScript** (Interface) — One language from the database call to the button, with the types checked at the boundary between them. - **React** (Interface) — For interfaces with state worth managing — anything signed in, live or multi-step. - **Tailwind CSS** (Interface) — A spacing and colour scale that holds across a large application without a stylesheet nobody dares delete from. - **Next.js** (Application) — Server rendering, routing and server-side data access in one framework, so permissions are checked on the server. - **Node.js** (Application) — The runtime everything else assumes, and the same language the interface is written in. - **Stripe** (Application) — Subscriptions, trials and failed-payment handling. Card details never reach the application. - **PostgreSQL** (Data) — Relational, boring and correct. Tenant isolation and constraints belong here rather than in application code. - **Prisma** (Data) — Schema as a file in the repository, with migrations reviewed like any other change. - **Redis** (Data) — Sessions, rate limits and job queues — the state that should disappear cleanly if it is lost. - **GitHub Actions** (Delivery) — Tests, type checks and the performance and accessibility gates run on every push, not before a launch. - **Playwright** (Delivery) — The handful of journeys that must never break — sign-up, checkout, enquiry — tested in a real browser. - **Docker** (Delivery) — The same environment locally and in production, so "it works on my machine" stops being a category of bug. - **Cloudflare** (Delivery) — Edge caching, DNS and protection in front of everything we host. - **Claude and GPT APIs** (Agents and workflows) — Model calls for classification, drafting and qualification, always behind our own validation. - **Vector search** (Agents and workflows) — Retrieval over your own documents, so an agent answers from your content instead of its training data. ### Questions **Can you build the first version before we have funding?** That is the usual case. The first version is deliberately narrow — one job, one plan, one way through it — because a product with four half-finished features tells you nothing about demand. It is bought as a fixed-price phase, so the cost is known before it starts. **Do you take equity instead of fees?** No. Fees only. An equity arrangement makes us a shareholder arguing for our own preference rather than a supplier you can replace, and it tends to end badly for the founder who has less legal support in the room. **Who runs it after launch?** Whoever you want. Some clients take the codebase and hire in-house once there is revenue to justify it; others keep us on a monthly engagement for releases and upkeep. The handover is the same either way — your repository, your infrastructure accounts, written documentation. **How do you handle payments and data protection?** Card details never touch the application: payment is handled by a PCI-compliant provider and the product stores only the subscription state. Tenant data is isolated at the database layer, backups are tested rather than assumed, and GDPR obligations such as export and deletion are built rather than promised. --- ## Social media management Social media management here means owning the whole loop: deciding which channels are worth being on, producing content that can actually be sustained, publishing on a schedule, and replying to what comes back. The work is consistency over months, which is the part that decides whether any of it compounds. URL: https://drasyo.com/services/social-media Updated: 2026-08-10 ### What is included - Channel strategy - Content calendars - Post & reel production - Scheduling & publishing - Community management - Analytics & reporting - Paid social ### How the work runs 1. **Choose the channels** — Fewer, properly. A thin presence across five platforms performs worse than a consistent one on the right two, because inconsistency reads as inactivity. 2. **Design what is sustainable** — We build the content mix around what your business already produces, so it can be captured as a byproduct of a working week rather than needing a production day. 3. **Publish on a schedule** — A calendar you can actually hold to, with a buffer. The most common failure is not bad content but a strong month followed by silence. 4. **Reply and review** — Community management is the half that gets dropped. Monthly reporting covers what earned engagement and what to make more of. ### Questions **How many posts per month do we need?** Fewer than most agencies quote, and consistently. A sustainable two or three posts a week beats a plan for daily posting that lapses after six weeks — the lapse undoes the impression the volume built. We set the cadence against what your business can genuinely supply material for. **Do you write the content or do we?** We write and produce it, working from what your business does — jobs completed, work in progress, questions customers actually ask. Anything requiring a claim about your business goes to you for approval before it publishes. We do not invent detail to fill a calendar. **Which platforms do you work on?** Whichever ones your market uses to ask for recommendations, which is usually one or two rather than all of them. For most Malta businesses that is Facebook and Instagram, sometimes LinkedIn for B2B. We would rather tell you a platform is not worth your money than bill for posting into it. **Is social media worth it if we already rank in search?** They do different jobs. Search captures people already looking for what you sell; social builds recognition with people who are not looking yet, so your name is one of the ones mentioned when someone asks for a recommendation. Neither substitutes for the other.