Cashm8 has been one of the longest running projects that I’ve been developing. It is a point-of-sale system (POS) which included the development of a 

 for customer facing sales work in restaurants, a back-end application to handle the business logic and persistence of data, an administration panel to manage things such as products, sales, payment devices etc. and finally a kitchen application that notifies kitchen staff when a new food order is received, so they can start preparing it.

This project has required me to learn new techniques and technologies. The biggest one here is the development of mobile applications using a hybrid framework named Flutter, developed by Google. I picked this technology because it offered me to deploy the application for both Android and iOS (if needed) with very negligible performance hit.

The mobile application acts as a cash register. It displays all sellable products to the user so they can input the customer’s order and receive payment on it. The application is integrated with two payment terminal systems, Poplapay and Viva Wallet, who handle all monetary traffic for card payments. Cash payments are of course an option as well.

You can browse for more images in Google Play.

Developing a mobile application has given me perspective on the release cycle of these applications and how dependent they are on these big tech giants. Google controls the Play store, while Apple controls the App Store.

Releasing a mobile application on these stores is a process that takes some time, and any changes you work on must be tested thoroughly to make sure you do not release a faulty version out there. It also brings an issue with versioning, where you need to maintain backwards compatibility for a good while.

Luckily, from pretty early on, I introduced a popup to prompt users to update their app version, which helps with pushing people to a newer version rather quickly.

The back-end application is less intriguing as it’s a REST API developed on top of Azure Functions, with Azure API Management instance in front. I chose the technologies as they offered rapid development, with no maintenance cost for infrastructure. I also chose Azure AD B2C as the identity provider, which was easily integrated with API Management.

Right now I am rewriting this application to follow the most recent programming model by Azure Functions, which offers a lot more flexibility in design terms.

By using Azure Functions the running cost of the whole system is around 8$ a month as well.

The admin panel acts as a UI for users to control their company’s products, sellable items, sales, payment terminals etc. It offers you a way to monitor your sales and download reports for accounting.

This application was built on top of Next.js framework (TypeScript + React) and deployed to Azure Static Web App service.

This application is also a UI, but for the kitchen staff. It polls the back-end API for any new food orders and gives out an alarm for staff to notify them that a new order has been received. The staff can then control the status of the order and take it through their process, finally marking it as complete.

The application also tracks the completion time of each order, from start to finish, so kitchen staff can measure how long it takes to complete each order.

Cashm8

 re-design and development project for The Finnish Esports Federation, when they contacted me about a new project they were pursuing. I had a short meeting with the executive director of the federation at an ongoing LAN event to discuss the details.

The idea was to create a portal where people could see all the esports matches for Finnish teams across all tournaments and games. We quickly discussed possible solutions for the platform and a budget. I had to submit my offer within weeks for their monthly meeting.

I sent the client two different offers with different platform solutions.

Wordpress. I gave this option for two reasons. The client had already been using Wordpress for multiple years now so they were familiar with it. The other was that it could speed the development by offering an admin panel out of the box. I did however mention that Wordpress as a solution would not be optimal for later development. I also felt a little uncomfortable using it as I would’ve most likely had to write custom plugins or other solutions, as this was a time before I even knew about headless Wordpress themes.

Laravel. I had never used Laravel before, but I knew it’s reputation. I knew it was a great framework and I could easily complete the project with it, even though it meant I had to write the administrative panel myself. I felt kind of excited to present it as a solution, because it meant I got to play with this new toy. I also expressed to the client that this framework would have way more agility in terms of developing the platform further.

They chose Laravel for the project due to the fact that they could continue working with it to extend the platform, which they’ve done.

The initial step for the project was to create the design for the website. The federation’s own brand guidelines were to be followed which meant using a specific color palette, blue being in a major role. The typography was something they did say could be changed as the guidelines were more for print, not web.

I started with wireframing. The website was to have a list of the closest upcoming matches, selection by game category, news, list of results and so forth.

I apologize, but this was the only wireframe shot I had saved

After the wireframing was cleared I moved on to the design. I built a simple style guide along with the design so that the design would match across all front-end views.

As the design progressed we made some clear changes to the plan laid out in the wireframes. The game category selection was left out. The frontpage should have a list of promoted matches. Partners or vendors should be promoted.

I made those changes and designed three separate view; the frontpage, single match page and static content views for articles and pages.

As the design was cleared I moved on to development.

I had two months for development, which I split up between one month of coding and one month of testing and fine tuning with a pilot group. I timed this so I could use my summer vacation on the project.

First I had to familiarize myself with Laravel. This meant everything from setting up the project, how to make authentication work, how to use their template engine (blade), build controllers, use migrations, routes etc.

The most interesting part about the framework I found, was the Eloquent Model and ORM. I generally don’t like ORM on frameworks and systems I don’t know, because it hides the persistence logic and I would like to see. However, this is a very common approach and I’d already seen it in CakePHP. It didn’t bother me too much.

Laravel uses an MVC model, which meant that I had to start by designing models. This meant things like a Contestant, a Game, an Event, a Match etc. In addition to these I developed support features to help manage the platform, which I will go into more detail below.

Laravel has good documentation, so it didn’t take me a long time to get everything rolling and I deployed out a nearly completed platform in three weeks, to a development environment. I used 

 (community fork of the now abandoned Semantic UI) for the dashboard’s styling as I didn’t want to spend any extra time thinking about the styles and design choices for the admin panel.

I developed a role based access control system for the platform so that the client could manage user permissions through roles. I set up permissions across the system which could be attached to said roles. This leveraged 

 feature which funny enough, was very similar to something I developed for my own application a couple years back.

A small REST API was required in the the second phase of the project, which would allow registered vendors to add and update matches, as well as retrieve them, from their applications. For this I had to write up a short documentation page using HTML. You can see this at 

Any esports related news articles from external media sources are fetched as a scheduled task from multiple RSS feeds and cached locally.

There is a simple filtering and search functionality for matches, which in hindsight is not as optimal performance wise as I’d like. For this I implemented an offset pagination.

I developed an event calendar with events fetched from 

 and cached locally. The calendar itself is rather simple, displaying events across days and displaying their details. I had to extend the Wordpress REST API at 

Each match has a set of contestants, game details, tournaments/event relationship, time, score, format etc. There are also streams, which are also linked to a match.

Stream status and details are fetched from 

The code repository is hosted on Atlassian’s Bitbucket

We deployed the entire platform on AWS (Amazon Web Services). I talked about different options with the client, but because the platform sends out scheduled emails to vendors notifying them of matches they haven’t closed or updated, we needed a reliable email gateway. I suggested AWS Simple Email Service, which was pretty easy to set up considering Laravel supports it out of the box. Plus it’s 100% free with the number of emails the system sends out.

Another reason we chose AWS was because the Federation is a non-profit sports organization, so they applied for the AWS credits - and were approved for them. I deployed an EC2 instance and an RDS database for the platform and set everything up.

We did reach the primary goals that we set out for this project. Unfortunately we did not reach a bonus goal, which was to automate most of the match data fetching for the platform.

There are numerous games and they all have (or don’t) their own APIs. It was beyond the scope of this project to start integrating them all and some would require gamers to set up those integrations for each of their matches or tournaments. The client settled for having an API where vendors could add matches to and then update the results, plus having some volunteers update results on the platform itself.

There are also some websites which have the same idea, but they are solely for one game only. Some sites have automated data fetching, some do manual work with a volunteer staff, which is how this project shaped out. 

 is a prime example of how an automated data fetching platform works. They have a bot (HLTV) which can be set up to the game server and that bot sends them real time data of the game to their API.

SEUL Ottelut

Back in 2017, when I was more involved in the esports community, I got approached by the Finnish Esports Federation because they had problems with their website. It was very slow to load and had features missing. They asked me to take a look and fix some of the problems.

The slow load times were of course caused by multiple Wordpress plugins being installed and active at the same time. The missing features were due to bugs which were hidden by the fact that it was a production deployment and no one had looked at the logs.

A year later the federation was asking out bids for their website re-design project, which involved creating a new design and after that, Wordpress template development. I got hired for the project.

We started with a brainstorming session and kept in touch for the duration of the project in Discord, talking about what the site needed to improve on. One major thing was the 

The federation had a good amount of content and the current sitemap wasn’t exactly the best and easy to navigate. They took upon themselves to think about the information architecture side while I would be responsible for making the design fit the needs and make sure all pages were easily accessible.

The primary goals of the project were to improve readability, make finding content easier and as a bonus, optimize speed.

The website, as I said, already had a lot of content so none of it should be lost. Instead, the project should only fix current content, move it or extend it, but not delete. This meant I had to work with an existing Wordpress installation database.

We talked about the features on the site and what new ones to add. One notable feature was the event calendar, improved news feed and of course Twitter. They already had some custom post types set up for members of the federation, the staff and so on.

Once we got the specifications in order, I started work on the UI.

Two years ago I wasn’t really familiar or comfortable with user experience (UX), so I didn’t really do any proper research with actual users on this project. Thinking about it now I really wish I had. The client’s website was a prime target for this type of research as they had a very consistent and constantly growing visitor base. I would’ve gained a lot of valuable information.

Instead I simply started with a moodboard and went through similar designs and executions to find some ideas on how we could improve the current site. The Federation’s brand guidelines set some rules for the design.

After this I moved on to sketching, starting with the front page and moving forward from there. This was the first project I used 

I of course chose a light theme for the design with blue being the primary color as per the Federation’s brand guidelines. I chose a more lighter paragraph color to highlight the titles on any listing pages.

Two years ago I didn’t spend a lot of time creating wireframes for customers who pretty much gave me free rein over the design. Instead I jumped straight into creating design sketches that gave out the impression of what the site might look like once in your browser.

I basically completed four sketches with which the client was satisfied with: frontpage, article page and static content page with navigation, plus mobile preview. After this I could move on to development.

Wordpress was rather simple. I created a completely new template, which is pretty basic, and tried to keep the plugin count to a minimum. Plugins that I did include were things like Pods, which was already in use as there were custom post types that the site needed, CloudFlare caching, event calendar etc.

I did note the requirements of the project in development, which included things like proper access to the navigation and child pages, the featured news and most recent tweets or media posts etc.

There was nothing really special about the template development. I used 

 with the interactivity. I wanted performance and load times to be optimal, but unfortunately the biggest issue with this was the server host.

The client didn’t want to migrate the site from the existing server, which seemed very slow to respond. I optimized the site as much as possible, but given the chance now, I would rather develop the front-end using modern frameworks such as React or Vue.js for speed and move Wordpress to AWS Lightsail or just another server entirely.

The website is now fully maintained by the federation and they keep redesigning and implementing small improvements on the site.

SEUL

Lantrek is a unique case in my portfolio. It is the longest ongoing project I have participated in.

Lantrek is an annually organized LAN event (computers and gaming) in Tampere, Finland, with nearly 1500 participants.

The history dates back nearly a decade, to 2011, when I participated in the event with a small party that wanted to live stream some games from the event. I helped them set up the stream and introduced myself to live streaming for the first time.

The next year I was working at Lantrek, setting up the live stream for the event, working as part of the staff. From there I started to be more involved.

During the years I’ve worked as a staff member and AV crew team leader. I’ve worked as the event’s graphic designer and as a software engineer. I’ve designed and developed the event website since 2015, majority of the print work and live stream graphics. So there’s a lot to go through here, but instead of going through the history, I’ll rather categorize these to just the graphic and development portions.

Each year is always different. We’ve always start by selecting a theme around which we design everything.

Each year the process starts with selecting an illustration or a photo. We’ve settled for stock images as I myself am not the kind of designer who can create major illustrations and we’ve tried finding someone who might be interested in doing something like that for us, but so far we’ve come up empty.

Either way, the work always starts with the theme and from there we start working on the print and website design. Website is often released first, as it’s the fastest and most flexible channel for information we have regarding the event. Posters are distributed soon after the launch for maximum exposure time.

I designed the current Lantrek logo back in 2015. The old logo was somewhat hard to use, very unbalanced and designed using Photoshop.

I wanted to create a symbol that people would easily recognize, that would still fit the theme of the event. You can guess how the symbolism is tied to the name, which contains a reference to a specific pop culture TV show.

I wanted to keep the original rocket/spaceship symbol but make it easier to work with, having more straight lines instead of curved ones and boxing it somehow. The font I chose was DIN Bold, with small customization, removing some cross lines from characters making it look more futuristic.

The primary color I chose was blue, but as with each year we selected a new theme this became irrelevant in the bigger scheme of things.

Each year I design at least the following things for the event:

In addition I’ve sometimes created simple video loops with partner logos for the stage in different sizes.

Photos by Atte Haapalahti and Lauri Ellilä, Lantrek

As I described above I worked as the AV crew team leader for two years, during which we managed to send out the first ever live TV broadcast from the event. We broadcasted the Counter-Strike: Global Offensive tournament finals to Finland’s national TV station, YLE. I was the executive producer at Lantrek for that particular job.

I designed the broadcast specs and built the team for the project, which consisted of a camera crew, technicians, director, graphic director etc. I started the work on that project 9 months before the event.

It was quite an experience and we managed to pull it off great. Those were one of the first TV broadcasted events in Finland when it comes to esports.

I’ve been designing, developing and maintaining Lantrek’s website since 2013. We’ve jumped from a custom CMS, to Drupal, to Wordpress, and now a custom CMS once again. We’re now developing Xerberus in association with Lantrek to have a modern ticket sales system in place for the event, along with CMS features.

The website tech itself is nothing really special. We always start with a UI design and gone from there, but this year we got around to doing proper UX research for the 2021. With each CMS platform we developed our own template and worked with that.

I won’t go into past events, as I don’t find those to be anything really special, but rather focus on the upcoming, which we will hope we can set up, but with COVID-19 going around it seems quite difficult.

Either way, as I said, I worked with another designer this year around and we did proper** UX research** this time. I went through the analytic data of our previous years visits, and we sent out a user survey to last years visitors, via email.

Analytics data showed that 90% of the visitors originated from Finland, with over 50% being mobile users. This proved that we should still continue to focus the site being in Finnish first, English second. Mobile use should be the focus as that number will more likely increase in the future.

Majority of the users visited two pages in particular: Tickets and Program. Third place was first time visitor guides. This meant we should focus on highlighting those pages and make them easily accessible. Readability is very important, as we received feedback that the earlier site was not very easy to read.

We are now focused on improving the information architecture on the website, making content easier to find. A search would be very beneficial to this.

Many people hoped that the ticket shop would get an upgrade, which we’re trying to do with Xerberus. The event now uses an old system which is free for use, but very clunky.

I will not be taking credit for this year’s UI design. It was a joint effort with another designer. I did the wireframing and sketching while she designed the UI.

We’re pretty much done with the design and moved on to developing the front-end with Vue.js (Nuxt.js framework). It’s still in very early phases and I can’t share more details about it at this point.

Lantrek

 was a personal project that I developed between 2016 and 2022. 
Unfortunately as time progressed we realized that working on a system of this scale would consume too much of our time and we were not close to making the system operational. In addition, we saw more and more SaaS solutions rise up in this space that fit our needs.

 It was a great experience, though. I learned a lot and used new techniques and technologies on this project. We did consider open sourcing what we had developed, but making that happen would still not absolve us from the responsibility of further development and the project was not in a place where we could proudly present it to other people. So we decided to abandon it.

As I worked in various gaming and computer events over the years, I begun to see a common problem. Each event had three systems to manage their website content, ticket sales and tournaments or competitions. This felt quite complex for the organizers, but even more problematic for the visitors if the event’s homepage didn’t indicate clearly where each system was located in. Often times this resulted in visitors asking where they can sign up for tournaments or see the seat map.

I saw this as a problem I could fix. The idea was simple. There should be a platform that has content, tournament and ticket management systems all in one dashboard. So I got to developing the base of the platform.

I started real work on the project in 2016. I used an open source PHP framework, which was very lightweight and already used in multiple sites, to build the base for the application. This allowed me to write everything by hand, from the start. The platform used a simple MVC model.

The first things I completed was of course user and site management, along with the login and registration process. From there I developed features like Articles, Pages and Menus. With these I had to design and develop a simple dashboard to control everything.

The first website I hosted using the platform was 

The platform has a multisite feature, meaning multiple websites are hosted in the system with different templates.

This feature had one great benefit: All users could use the same account to log in to multiple websites that were hosted on Xerberus, meaning they could sign up for events using the same credentials. I of course enabled SSO login via Google, Twitter and Facebook (now removed) so that users don’t have to add their password to the system, if they choose to register via those providers.

It does have it’s bad sides. One major drawback is that websites don’t have any real control over their own template, because I failed to create a customization feature for them. The code is closed source.

I did play around with the idea of using Twig template engine in sandbox mode, so websites can’t do any harm to the system that way, but version control was problematic in that scenario. I didn’t spend any more time on it and dropped the idea.

Once the CMS portion was done, I moved on to the tournament side which was the highlight feature. Initially I worked on the project with another developer who had built a tournament system for LAN events using CakePHP 1.3 back in 2015. It started to get really old. CakePHP 3 was already out. I tried to take on upgrading it to CakePHP 3.0, but the task seemed very gruesome, so I asked if I could use his code on Xerberus and he agreed.

I managed to migrate his code to Xerberus with his help and we got the Finnish Esports Federation interested in the platform. They wanted to sponsor it to some degree and host their upcoming league there. Some LAN events followed.

Unfortunately I didn’t have as much knowledge about the esport and tournament domain as I should have, and this occurred to me as I begun the thought work on version two. I consider the tournament feature something I should’ve continued to develop much further with domain experts, but I got busy with other stuff and kind of dropped it too.

Integration with the Finnish Esports Federation’s player lisencing system

One of the main reasons the federation took interest int he platform was because they wanted to use their player licensing system with the league they were setting up. Each player or team who wanted to participate, should be a licensed player, and that license needed to be verified when the user or team signs up for the tournament.

We had a meeting about it and I developed the integration into Xerberus. Each user could access his licensing information on the system (read only). The licenses are synced from an external API in 15 minute intervals and new users are checked against the registry so the license is immediately available.

While the system used an MVC model I developed each feature as a separate module. This allowed me to immediately see all the features the system has and made it easier to work with. This also enabled me to developed a magic router, which created routes based on /{module}/{method}.

I cannot remember the primary reason why I later replaced that magic router with the 

 -package (not the easiest to implement, btw.) I also rewrote the entire namespace at the time, and core functionality, to make it more component based with a proper bootstrap sequence. Earlier it’d been a horrible single file script that I wanted to break apart.

As the app grew, I started to feel like an MVC model was not sufficient enough anymore, as there was so much business logic involved to some features, and it would better to use layered architecture. As a much less experienced developer as I am now, I also made some design mistakes I wanted to fix in version two.

As time passed since the initial launch in 2018, I noticed the biggest flaw in the system was that it didn’t have enough customization, nor a proper API. I wanted to give events and organizations the ability to develop their websites however they like, or at least customize them.

This is when I realized I wanted to rewrite the platform as an API only, but with opinionated approach to certain content types so organizers don’t have to build them, or think about their inner workings. I decided to start from scratch, still using PHP as a programming language, but picking Slim Framework as the base for the platform and using GraphQL as a query language for that API.

I begun developing version 2 after the failed launch of our new ticket management system in November 2019. We worked intensively for 2 months to get the system up and running, but failed when the deadline started creeping on us and I pulled the plug on the launch. The customer luckily had a fallback plan and managed just fine.

During the development of the ticket shop we started using 

Slim is a very un-opinionated micro-framework that I’d already worked with back in 2016. It doesn’t come with anything extra and supports multiple PSR standards. It’s a great starting point for a project where you want the framework to have as little control as possible when it comes to the design of your app.

Compared to a REST API, GraphQL is more suitable for any type of device be it desktop or mobile, as it removes any overhead from requests. I wanted the network requests to be as small as the client wants, and optimize the back-end based on that. You can easily use field resolvers to prevent any extra trips to the data store in cases where clients don’t request that information.

Development wise GraphQL is no harder than REST API with proper schema documentation. You just need to design that schema up front, and not as you go along.

We were already building the ticket system using Node.js and GraphQL, which is why it also seemed like a good fit. I could still write basic REST API endpoints with Slim Framework if I wanted to.

I wanted to implement a design system for the new version, so I decided to use 

. A very interesting design methodology, which works perfectly with applications that are mostly component based.

I read articles on Medium about how some had used Atomic Design and categorized some web components under atoms, molecules and organisms. This helped me a lot because I now had three distinct categories and a list of components I had to design.


This served as a great base to start developing the dashboard using Vue.js (Nuxt.js framework). The components have evolved and do keep evolving as I progress forward in the dashboard design.

Before I could start developing the dashboard, I first had to create a login and registration process. I wanted to implement a safe authentication process and a system which would allow users to approve the applications (clients, systems, platforms) they were signing on to. I picked 

I didn’t write the server myself, and rather used a popular pre-made library for this, but implementing it was quite a process. I had to write multiple models and repositories which implemented specific interfaces.

Having OAuth 2 allowed us to create an authentication flow, where users can simply log in to another Xerberus client’s platform and have them approve the request before moving forward. This was something I had already done before without OAuth 2, but now we also had to consider mobile applications, not just websites.

We can now support PKCE, Authorization Code Grant and Client Credential flows. I had to write a feature that allowed the generation and revoking of client credentials, but that was a minor addition to this.

We now had three developers working on the project and I didn’t want anyone to drop out of the loop as OAuth 2.0 was quite tricky, so I started to look for an internal documentation system where I could write what each feature is supposed to do, how you can log in, how OAuth works, how we communicate between the App and Store services etc.

I wrote an article about this quick little side project on 

 which you can read, but to summarize I ended up writing the documentation tool using Contentful and Next.js.

It worked out perfectly as we now had a free internal documentation tool which supported static pages, with a flexible WYSIWYG editor and search functionality. A very basic tool that did the job. I applied the design system components to this too.

While the design is a big part of the system, most of the work is to be done on the tech side. The shop (tickets) is already built using JavaScript (Node.js) and the App using PHP. Two languages I’m most comfortable with.

Both systems use a relational database and communicate with each other using API’s. GraphQL is pretty much self documenting (with minor comment additions) and available for all registered accounts to consume how ever they like. We’re hoping to build a pricing system based on API usage later down the line, as we now have a single endpoint we can easily hook such monitoring into.

I am using Domain Driven Design on the App to create a modular codebase, that’s relatively easy to navigate and understand.

We’re running the whole platform on Azure where we can leverage services like SendGrid (not really Azure, but they have some type of integration for it), Storage, Functions etc. We can spin up test environments faster and even host our own private npm repository on Azure DevOps. It’s also much more reliable and fault tolerant than a single server.

 as the front-end framework to remove the need to write stuff like routing, state management, code bundling etc. We chose Vue.js because everyone except me had more experience with it and I simply wanted to learn something new.

As we’re building away we’re also writing proper tests this time, and doing manual testing on the front-end with hopes that we can use Cypress later to test that too, if we gain enough popularity and have enough time. I am currently migrating the functionality while also splitting the code from an earlier MVC model to layered architecture containing things like controllers or resolvers, services, models and repositories.

Xerberus

Web1 is a Finnish cloud / hosting service provider, who work with different clients to figure out the optimal solution for their needs. They also provide out of the box services for anyone who just wants to get a webhotel up and running, or an email inbox set up in O365.

I was contacted by one of their partners, because they had a problem and asked if I was available to work on it. The issue became very clear once we had our initial meeting. They had a website for the company, which worked as their landing page, and 

, which worked as their hosting automation and product management platform for customers. These two looked nothing like each other.

- You can read the entire case below or just visit the final result at 

I had a short brainstorming session with the customer, and we kept in direct contact over Slack for the duration of the project. We went through both platforms so I could have a sense of what they were like.

Both systems had a free, pre-made, template in use which didn’t resemble each other at all. When a user visited the website and then jumped to order a service, he received a shock that the platform looked completely different and might even start to wonder if I should complete my order now.

We immediately decided that both systems needed to have the same design, so that the visitor is not discouraged when jumping between the two. If we could, we should integrate the two to some degree, meaning displaying shopping carts and profile information on the website.

With these we had certain goals to reach:

- Creating a design that fits the company brand (which designed last year)

- Making the transition between platforms more smooth so that the user is not shocked when switching between the two

- Creating a more credible order process for the customers

There were technical limitations to this project which I will go into more detail below.

I started the UX process with competitive research. Some things I saw that were repeated were:

- Each website had their pricing displayed as a monthly fee, instead of yearly. This is quite substantial. Firstly, it gives out the impression that this service is actually charging low prices. You tell someone a service costs $4,90 a month, instead of $58 a year, he’ll more likely opt out for the monthly fee even though they’re the same. Secondly, it immediately presents the user with the option to cancel his ‘subscription’ to these services whenever he likes, and he won’t be billed next month. Much like many services these days such as Netflix, Amazon Prime etc.

- Most websites clearly tried to answer the question WHY US? Most sites promoted their customer service response times and availability. Some bigger ones had user stories they shared. Most user stories had a person’s face attached to them so that it brings out a more human feeling.

- Hero headers were common and used to advertise the platform itself, or some current sale they had ongoing

- Products and services were easily accessible from the menu

- Contact information or “Contact us” links were easily accessible and visible most of the time when browsing anywhere on the platform. Some sites had a chat feature.

- Sign in / Register buttons were also very accessible, which is pretty common

Unfortunately I couldn’t do any user research with existing customers. I decided to skip it also partly because of budget constraints. Instead I created most common user flow scenarios and tried to find any possible red routes.

While the flow was really clear in my mind before starting development, some red routes became known during testing which I was unaware of and could not fix later. One of those was domain registration. The user first picks a domain, then moves to configure it and he’s presented with the option to select 1. his own nameservers 2. have Web1 host the domain. If the user selects option 2 he’s redirected to a product page where there’s only a single product: Domain Hosting (free). The user has to add that product to his basket as well, and then move to checkout. I would’ve liked to add that product in the configuration page if the user opts for option 2, removing the unnecessary step, but it proved really difficult to do as we had no access to the source code for the platform.

I then moved on to wireframing. I created multiple wireframes starting with the frontpage all the way to the order process and service management dashboard.

I wanted the frontpage to have a clear pricing table for the most commonly sold top level domains, as a domain is the first step in setting up an online presence. It’s determines your company’s mailing address on the internet and is really important, plus they’re very cheap (like the candy aisle in a store

I also thought the frontpage should contain the following things:

- Hero header introducing the company and it’s services

- A feature list answering the question ‘WHY US’

A “Contact Us” link is clearly visible on the menu and accessible at all times. The link is also on the hero header as you land on the homepage.

After the wireframes were cleared, I moved on to UI design. This meant designing, of course, the front page and product pages, then some of the order process pages on the service platform. This was quite simple after I cleared the wireframes with the customer.

The customer’s brand guidelines determined the color palette, which was that a red-pink color titled Persian Rose acted as the primary color. Blue was the secondary color and worked for illustrations which pops them out from the websites quite nicely.

I selected Poppins ** as the heading font due to it’s roundness, weight and crisp look. Paragraph font is **Roboto, which is a bit more condensed and easy to read. Very popular and used by many companies.

I picked open source illustrations for the website to bring out some personality to the site for each page. A light theme was preferred instead of a dark one.

I presented the customer with some feature options. One of those was a comparison table for webhotels. This would give the visitor with clear options suitable for his needs and he could make a clear and conscious purchase decision.

The product cards, I felt, should contain a short introduction, or “sales speech” followed by the price and then feature list. The Add to basket button is of course very visible, even though located at the bottom of each card. This way the user knows what the package contains immediately and can then look at all the features, while knowing what price range he’s at.

The frequently asked questions was a feature I pitched to allow the customer to avoid spending time answering clear questions visitors might have about services or the company, such as:

Each page has a list of general FAQ questions, or page specific ones.

When the project started, we selected a stack for the project. There were technical limitations with Hostbill, which I already went through to some degree (closed source code and low visibility to how the requests worked). I did propose that we could write a more extensive integration and maybe select something like 

 for the project, but the client was clear with the limitations that using Wordpress brought and it was fine for them.

Hostbill had a REST API, with very slim documentation which did not cover all possible features, and I deemed it would be risky to start developing a complete integration using the API, and with budget constraints I couldn’t start prototyping with it. So we decided it would be simpler to use forms and redirect the calls at the platform to start the order process. This way the transition is somewhat smooth in addition to saving time during development.

The stack for the project consisted of building the front-end using React, having 

 as a headless CMS which fetched product information from 

. I wanted to use React simply because of the speed a decoupled front-end like that brings to the table.

To save more time in development I picked a React framework designed for Wordpress only, titled 

. This made working with Wordpress relatively easy as the integgration is already there and I could simply connect to the API.

article about using Frontity with Wordpress

Extending the REST API in Wordpress is rather simple. You simply define a namespace and create routes with callback functions that return a response that gets converted to JSON.

I wrote custom post types for the website, such as:

- Blocks - Editable content for a specific block area in a specific page (this feature idea is originally from Drupal) so the customer has more control over everything on their website

- FAQ - Page specific or global questions and answers

I wrote all custom post types as classes. This way I could isolate the functions and not have to write each as a global one, making code navigation simpler, even though there isn’t much custom code. There was a total of 10 endpoints I added to Wordpres which simply returned data, such as the menu, products. blocks for each page etc. I used the REST API exposed by Contact Form 7 plugin to enable the contact form to work from the front-end. I had to use native JavaScript to capture the submit event from the form, because the HTML was generated by the plugin and rendered with React.

Frontity itself is just like any other React framework and it has an opinion of it’s own. Frontity brought several benefits to the project.

- I didn’t have to write the integration with Wordpress REST API myself. It was already there.