Teemu Paakkunainen · MSc (Econ.) · Kaarina, FinlandA marketer who ships ideas to production.

The brief

A moonlight climbing event on 26 September 2026 needed a campaign that ties together the chain's four parks. Instead of just an ad, we built a game: each park has its own level, the leaderboard is public and the best players win tickets. The winner chooses the park.

What I did

• Defined the concept, the character of each level, the difficulty and the prize mechanics.
• Led AI-assisted development with two assistants and brought their work together.
• Tested on real devices and tracked down bugs, such as touch controls that released when a finger slid over the edge of a button.
• Set up the database, deployed the game to the server and published two language versions in WordPress.
• Designed the ad creative in Photoshop and set up the campaign in Meta.

After launch

• The first days with real players showed what automated tests cannot. I moved score submission and instructions to their own screens, which removed scrolling from all 40 measured screen sizes.
• The leaderboard now shows only the best score per nickname, and the same run cannot be submitted twice.
• Ähtäri was added as a fourth prize park because it holds its own event on a different date. The database check constraint was extended before release.

The brief

Every adventure park visitor accepts the safety rules before going on the courses. This used to be done on paper at the till. The goal was a form that can be filled in on a phone at home or from a QR code in the park, across four parks and three languages.

What I did

• Led the development of park and language specific forms for Turku, Tampere, Ähtäri and Vierumäki in Finnish, English and Swedish.
• The form validates ages and required consents before submission: one adult and up to four minors at once.
• A confirmation screen is shown at the till, and every submission is stored in WordPress and sent to the park's own email.
• The cause of failed submissions was found: reCAPTCHA v3 scored real customers as low as 0.00. The protection was removed and submissions started working.

Retention and automatic deletion

• The forms also collect children's names and dates of birth. That kind of data must not stay in the system forever just because nobody remembers to remove it.
• Submissions are permanently deleted 366 days after they are sent. The deletion is automatic and it only touches the safety forms, not any other form.
• It runs from a server schedule rather than from page loads. The old schedule had been failing silently on an outdated PHP version, which only surfaced while building the deletion.
• For accident cases a single submission can be marked for retention. The mark always requires a stated reason and it blocks deletion until the case is closed.
• The same limit covers the form emails that pile up in the parks' mailboxes, so the data does not live on somewhere else.
• I documented the work technically: the data flow, the commands and the steps for handling a deletion request. A system must not depend on the person who built it.

The marketing angle

• Language specific thank-you pages trigger custom conversions in Meta Ads.
• People who filled in the form are excluded from retargeting, so the budget goes to those still deciding.
• Finding: group booking ads were optimising for the safety form conversion. Every campaign needs a conversion that matches its own goal.

The task

The safety forms carry an optional newsletter checkbox. Opt-ins piled up in the form archive and went nowhere. The goal was an automatic transfer into the email platform, with only the data that belongs in a marketing list. The forms also handle children's details, so data protection defined the solution.

Choosing the platform

• I first built a version on a familiar platform with its ready-made plugin. It worked, but I dropped it: the free tier was already too small, the price would grow with the list and the data would have left the EU.
• I read the plugin's source code. It guesses the email and name fields from the form. On a safety form the name field can be a child's name, so I defined the transferred fields myself.
• I compared five free options and picked an EU-based service: 2,500 subscribers on the free tier, automations included. It had no ready-made form integration, so I wrote one. That also gave full control over what data moves.

The build

• The forms, the checkbox and the fields stayed as they were. Customers notice nothing.
• The park comes from a hidden field and the language from the form ID, so subscribers land in park-specific groups automatically.
• The transfer runs in a background queue. An outage at the email platform can never block a safety form submission.
• A failed transfer is retried five times with staggered delays, and every transfer is logged. I built a command line tool for checking the connection and reading the log.
• Someone who has unsubscribed is not reactivated even if they fill in the form again. An existing subscriber is updated, no duplicates.
• The newsletter and the group offers have their own separate consents. They are stored in different fields and never overwrite each other, so either one can be withdrawn without touching the other.
• I authenticated the sending domain (SPF, DKIM and DMARC) and kept the strict DMARC policy even though the platform suggested a looser one. The privacy policy was updated in Finnish and English.
• The legal basis is consent. For every subscription the time of consent and the exact wording shown on the form are stored, so the consent can be evidenced later.

What I learned

A ready-made solution is not automatically the best one, even when it works. Cost, where the data sits and what the system actually does with it decided this. The API documentation did not match reality either: field identifiers came back in a different place than the docs said, and only testing against the real response revealed it.

The task

A restaurant site is not there to look good. It is there to say what is on offer, get the guest to book a table, and sell gift cards even when the kitchen is closed. This was client work, built as a pair. I was responsible for the build and the technical side.

What we built

• A menu in five sections and over forty items with prices. Dietary options are on the list itself, so nobody has to ask.
• A lunch page by weekday, with Wednesday burger day on top of it. The staff update the list themselves without anyone touching code.
• The burger of the month on the front page with drink pairings. It is also the strongest upsell spot on the site.
• Two locations on one site, each with its own details, opening hours and booking link.

Booking and sales

• Table reservations go to TableOnline through location-specific links, so the guest does not have to pick the restaurant twice.
• Digital gift cards are bought through TableOnline. The gift card is the one thing the site sells directly, and it sells while the restaurant is closed.
• Corporate orders and groups have a path of their own, because a single order there is worth more than one table.

Tech and upkeep

• WordPress was chosen so the restaurant updates the lunch and the monthly burger itself. A site must not depend on the person who built it.
• Performance was handled with caching and Cloudflare, because lunchtime traffic arrives on phones and in spikes.
• Cookie consent and a privacy policy were in place from the start, since the site has tracking and social integrations.

Published in 2023 and still in production in the same shape. Upkeep sits with the client.

Starting point

The old 2022 Elementor site worked but did not sell. The look did not match the price level, availability was not visible and every enquiry went through email.

What I did

• Merged six subpages into one page that carries the whole story and the booking flow.
• Built a calendar that reads the owner's phone calendar. The server extracts only the dates from the feed, so guest names never leave the server.
• Every booking request is logged before sending, so nothing is lost even if email fails. Spam protection uses a honeypot field and a timing check, no CAPTCHA.
• The price list detects the current season from the date and ski holiday weeks from the week number.
• Finnish and English at their own URLs, structured data as a lodging business and HTTPS enforced.

Core idea

For fixed broadband there is no product list until the address is known. So the journey starts with an availability check, and the address shapes everything after it: products, price, recommended equipment and whether an installation visit is needed.

Key solutions

• The cart separates monthly and one-off fees and shows the total contract value, the number worth tracking in sales and CRM.
• Checkout verifies that the order will work. Suggesting a missing router is not upselling, it is a prevented support call.
• Every recommendation logs whether it was shown, accepted or skipped. A rule that everyone skips should be removed.
• Existing customers see upgrades as a price difference, and the order goes to CRM as a contract change, not a new customer.
• A technical view shows what data the journey produces and where it would go.

The task

A portfolio should show the skill, not describe it. So this site is written line by line. No CMS, no ready-made theme, no JavaScript libraries. Every movement and every request is my own code, and I can explain all of it.

The quotes API

• The PAAK ticker at the top is a joke, but the quotes next to it are real. They come through a Cloudflare Worker that sits between the site and the data provider.
• The API key is a server-side secret. It is not in the code and never reaches the browser.
• Responses are cached for 15 minutes, so the provider is called about 380 times a day whether there are ten visitors or ten thousand.
• Three levels of fallback. If the API is down, the page uses a stored file. If that is missing too, it uses the values written into the page. The visitor never sees an error.
• One failing symbol does not take down the strip, the others keep showing.

Animations

• The dot field on the front page reacts to the cursor and first gathers into the p. logo before scattering again. Drawn on canvas, not a video or a GIF.
• The ticker line is drawn in real time, and as the price accelerates the logo catches fire and the whole bar tilts.
• The 404 page is a full-screen illustration with a layout of its own.
• Every animation respects the reduced motion setting and pauses when off screen. That saves battery and attention.

Fundamentals

• Two languages on their own URLs, a language switch and hreflang for search engines.
• Light and dark themes that follow the system setting and remember the manual choice.
• Structured data, a sitemap, descriptions and share images for both languages.
• Keyboard accessible, a skip link to the content and real alternative texts on the images.

Deployed on Cloudflare. The static files are one project and the API is a separate Worker that answers only on /api/.

The task

In competitive gaming the audience arrives through social media. The match has to be announced before it starts and the result has to go out the moment it is known. I designed and produced these graphics myself for two organisations. The esports team of the Swedish SHL club Örebro Hockey, and the Finnish organisation SJ Gaming.

What I did

• I built a template for every type of post. Game day before the match, line-up on match day and the result straight after the final whistle.
• The templates were made so that only the logo, the time and the numbers change for the next match. Everything else stays put, so the identity does not erode under time pressure.
• Player portraits were cut out by hand and matched to the same light, so six different photos became one line-up.
• Örebro's look was built around the castle in the city. A dark version for evening matches and a light one for daytime posts, with the same composition in both.

Sponsors and rules

• Sponsor logos are part of a contract, not decoration. Up to seven of them had to fit into the same bottom bar, each one readable and none covering the image.
• League marks sat on top and changed from match to match. The same template served both eSHL and ECL Elite fixtures.
• Each post was needed in several sizes. Landscape for Twitter, square for Instagram and a taller version for a phone screen.

What stayed with me

This was the first place where I did visual work to a real schedule and for real contract partners. A match starts when it starts, so the graphic is finished before that. The same thinking is still there when I produce campaign material today.

The graphics were published on the teams' own channels. Örebro's matches in eSHL were also broadcast on C More.