What we do
Services
Sold separately and built to work together. Visibility without follow-through wastes the traffic; automation without visibility has nothing to process.
- Services
- 06
AI visibility
Your customers are already asking AI.Is AI recommending you?
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.
- 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
Automation
Enquiries arrive at 23:40 on a Sunday.Who answers?
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.
- 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
Websites
Fast enough to rank.Clear enough to convert.
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.
- 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
Application development
The spreadsheet has fourteen tabs.Which one is the product?
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.
- 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
SaaS product building
Building it is six months.Finding out if anyone wants it is six weeks.
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.
- 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
Social media management
Search finds people already looking.Who finds the rest?
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.
- Channel strategy
- Content calendars
- Post & reel production
- Scheduling & publishing
- Community management
- Analytics & reporting
How they connect
Three things, in order: make you findable, make the site worth finding, and make sure nothing that arrives gets dropped.
The build services extend the middle of that chain: a website is read, an application is used, and a SaaS product is one you can sell. Social media management sits alongside the chain rather than inside it — same demand, different surface. Most engagements start with one service, not all of them.
What we build with
The layers we build in, and what we reach for in each.
Defaults, not rules. A project inherits whatever it already runs on, and we say so before quoting rather than after. Nothing is on this list that we have not shipped.
Interface
What a person sees, on the slowest device they are likely to use.
TypeScript
One language from the database call to the button, with the types checked at the boundary between them.
Astro
Ships HTML by default and JavaScript only where a component asks for it. This site is built with it.
React
For interfaces with state worth managing — anything signed in, live or multi-step.
Tailwind CSS
A spacing and colour scale that holds across a large application without a stylesheet nobody dares delete from.
Application
Where the rules live, and where they are enforced whatever the client does.
Next.js
Server rendering, routing and server-side data access in one framework, so permissions are checked on the server.
Node.js
The runtime everything else assumes, and the same language the interface is written in.
Python
For the data and model work where its libraries are simply better than the alternatives.
Stripe
Subscriptions, trials and failed-payment handling. Card details never reach the application.
Data
The part that has to be right first, because it is the part that is expensive to change later.
PostgreSQL
Relational, boring and correct. Tenant isolation and constraints belong here rather than in application code.
Prisma
Schema as a file in the repository, with migrations reviewed like any other change.
Redis
Sessions, rate limits and job queues — the state that should disappear cleanly if it is lost.
Delivery
How a change gets from a laptop to production without a person remembering the steps.
GitHub Actions
Tests, type checks and the performance and accessibility gates run on every push, not before a launch.
Playwright
The handful of journeys that must never break — sign-up, checkout, enquiry — tested in a real browser.
Docker
The same environment locally and in production, so "it works on my machine" stops being a category of bug.
Cloudflare
Edge caching, DNS and protection in front of everything we host.
Agents and workflows
The layer that does the repetitive work, with a person on the escalation path.
n8n
Workflow orchestration you can read as a diagram, self-hosted where the data should not leave.
Claude and GPT APIs
Model calls for classification, drafting and qualification, always behind our own validation.
Vector search
Retrieval over your own documents, so an agent answers from your content instead of its training data.
Not sure which of these you need?
Send us the site. We will tell you which of these is costing you the most right now, and what we would change first.