Every ticketing platform ships a widget. pretix documents its own plainly: paste two code snippets into your HTML. Twenty minutes of work and the event is on sale, in the widget’s fonts, in a box with its own scrollbar. Most small organisations selling tickets online have a page built exactly that way.
weinbergarlberg.at does not. Events are pages of the site, in the site’s own typography and layout, and the visitor reaches pretix at the point of payment. The ticketing platform underneath is the same one anybody could paste in. The development on top went into that UX.
What does composing tools actually mean?
The words and the pictures live in a CMS the association edits itself. The events read as pages of weinbergarlberg.at, carrying the design Oliver Schöndorfer drew for it. pretix owns the inventory and the money, and the visitor goes there when they are ready to buy.
Both routes use pretix. They differ in who owns everything between the first click and the checkout.
| Paste the widget | Compose the two | |
|---|---|---|
| What it takes to build | Two code snippets from the pretix backend, pasted into a page | Development against pretix’s REST API, plus the work on the content side |
| Who decides how an event looks | The widget | Your design |
| Where an event lives | In an embedded overlay on your page | As a page of your site, with its own address |
| On a small screen or without HTTPS | pretix documents that the widget may open a new tab instead | The page behaves like every other page |
| When the visitor leaves your site | At the first interaction | At the point of purchase |
| After a redesign | The widget still looks like the widget | Event pages change with everything else |
Worth picturing what that actually looks like on a page somebody designed. A panel arrives in another product’s typeface at another product’s line height, inside a box with its own scrollbar while the page scrolls behind it. The spacing lines up with nothing above it or below it. Tapping through mid-decision moves the visitor onto a different domain under a different header, and on a phone pretix documents that the widget may open a new tab instead, which is where a visitor who arrived from an Instagram link tends to stop. That is the UX cost of the widget, and on this project it was the whole reason to write the integration.
The widget is a decent product doing exactly what its documentation says, in about the time the documentation promises. A component built to render on any website in the world has to be neutral, and neutral is what shows when it lands in the middle of a page with a design of its own. The question is whether anybody told you there was a second option.
Ticketing is just the version of this we happened to build. The same fork shows up wherever a platform hands you a snippet: bookings, shops, event calendars, forms, member portals, chat. If you have pasted one into a page, this applies whether or not you sell tickets.
Why can a small association afford this now?
Because AI-assisted development collapsed the cost of the code between two systems. Reading an API’s documentation, writing the client, mapping its fields onto a content model, covering the error cases: that used to be billed in developer weeks, which is what put it out of reach. It is hours now, and hours fit inside a village association’s budget.
The obvious next question is why you would hire anybody at all. The typing got cheap. What the typing was wrapped around stayed exactly as hard:
| Got cheap | Stayed hard |
|---|---|
| Writing the API client, the field mapping, the error handling | Knowing that composing was an option before anybody proposed the widget |
| Getting a first version onto a page | Deciding where the seam belongs, so the visitor crosses it at the right moment |
| Producing something that looks finished | Owning the dependency the day the platform changes its API |
Our read is that AI-assisted development is killing the typical web agency, because a large share of what that model billed for sat in the left column. We argued the same thing from the other end in building is getting easier, running is not, where the generated page turns out to be the cheap half and everything after go-live is the half that decides whether the site holds.
Four things have to be true before the composed route is worth doing:
- A platform with a documented API. pretix publishes one openly, covering organizers, events, items and orders. If the platform you are looking at does not, that is worth knowing before you sign with them, not after.
- A CMS priced for the organisation in front of you. We chose ours here on boring criteria: cheap to run, quick to learn, and without a pile of machinery nobody in a small team will ever open. Our five questions before picking a CMS land on different answers for a scale-up.
- A site that is a codebase rather than a theme. Composition happens in the site’s own code, so there has to be some.
- Somebody who owns the seam after launch. The glue is cheap to write and it still breaks. Platforms ship new API versions on their own schedule, and someone has to notice and fix it in a week that was already full. That is question five below.
What does real development capability buy?
Control over the UX that the widget would otherwise decide for you: whether an event gets an address you can put in a newsletter, what loads first on a phone with two bars of signal, what happens to the page when an event sells out.
Without that capability, the honest answer to “can we sell tickets on the site” is the embed, because it is the only answer available. The scope quietly shrinks to whatever the tools do on their own. We hit the same fork on customer portals and anything behind a login, where the quick answer is to park somebody else’s product in a box on the page and move on. Building it into the site costs more, and it is the only version that behaves like your site.
What to ask before you hire someone to build it
Five questions, usable in an email, and the answers tell you more than a portfolio does:
- Will each event have its own address on my domain, or does it live inside the platform’s widget? If it is the widget, ask what the other version costs before you agree to it.
- Does the platform we are using publish an API, and have you worked against it? A provider who has not looked will tell you the embed is the standard approach.
- At what point does a visitor leave my site? There is a right answer for your case, and it is rarely the first click.
- Can you show me the same purchase flow on a phone? This is where composed and pasted stop looking alike.
- Who fixes it when the platform changes its API? Composition creates a dependency somebody has to own, and you want that named before launch rather than during your busiest week.
The association here runs a wine culture programme in the Arlberg region. They needed to sell tickets to it, which is roughly what a yoga studio, a small theatre, a museum, or a village festival needs. The build is not exotic and neither is the budget. It just required someone willing to write the part between the two systems.
If your events, bookings, or shop currently sit inside somebody else’s widget on your page, that was a build decision, and it can be made again. It usually starts with a headless website that has enough code of its own to hold the other systems inside your design.