Be warned! This post is a lengthy one and will take you approximately 20 minutes to read through, so bear that in mind if you're deciding to consume it.

Scrolling the web as a software developer we often come across funny text message screenshots, where fellow developers are asked by their friends, family members or semi-strangers to develop a killer mobile or web app for them, often because they think it is going to be a simple job.

I am here to tell you, that if you want that app to work, 

. Not if you expect your application to take off, and someone has laid the ground work for that.

Having worked in this field for over 15 years, I am going to try and describe everything that goes on during my normal development project and keep it as simple as possible for anyone to follow. It might get a bit technical, but I will try and adjust if needed.

The short point I am trying to make is there are a lot of choices that we have to make that impact the amount of work we have to do and it’s all dependent on the complexity of the problem we developers have been tasked to solve.

I will also try and keep this info package updated as I find mistakes in it, or discover new things.

Let’s start by covering what agile software development is, how I typically start a software project, what web and mobile development involves, to the trade-offs I have to make when selecting different technical solutions. All of this is to give any reader an idea where time is being spent and what choices we have to make.

Finally, I will share a case study from a project I completed recently that took over a year to complete.

I would like to start this brief into explaining what agile software development is, but before I can do that I have to explain the history behind it.

Agility was an idea that originated in the early 2000s from a group of established software developers / consultants, who had seen the failure in what was called the “waterfall development process”.

“Waterfall” consisted of making a huge plan upfront, having the customer sign off on it and then actual development could begin. The development phase often took from 6 months to over a year and typically ended with the realisation that the software did not solve the problem the customer needed. That was because the problem had evolved during that time, or because some problems were not discovered during planning. Nobody realized to talk to the customer during development. Instead it was decided that following the established plan was the key to success.

 for software development was drafted that contained specific values and principles that developers should follow, which I will summarise:

Developers should work in small steps and release working software often (nowadays daily or at most weekly) for customers or stakeholders to try out and give feedback on.

Developers should collaborate closely with the customer to discover if we are building the right thing and correcting course / adjusting as we learn new things during this process, or what we gather from the feedback.

The goal is to satisfy the customer and to give them the software to try out as early as possible. It might even be possible to have actual users use that software from that first release, but it might not be that appealing.

When you are thinking about starting a web or mobile development project, you often want an estimation on two things:

. They are relational to the amount and complexity of the requested features. Unless we have completed work like that over a hundred times, developers are unable to give an exact time (and thus cost) estimation on how long the work will take. We can just guess.

Sometimes people put together an estimate of hours that they will work on the project, and then hope that developers hit that goal. Most of the time they won’t.

We (developers) cannot know how much time it takes to do the work, so we can’t tell you how much it actually costs until we start working on the problem.

This is where agile software development will help you. Instead of an agreed plan, we should focus on collaboration.

Agile lowers risk and cost of being wrong

Agile software development tries to alleviate this uncertainty and 

 (and thus lowering cost) by breaking the work down into smaller, releasable, packages (or steps).

The idea is to work in small steps, release frequently, and get feedback on the work, so we can correct course as fast as possible and aren’t spending time building the wrong thing. Agility also enables the customers to pull the plug if they think the cost is running out of control, or development is not working out.

In the end you will have a piece of working software that you can use (as it was delivered as early as possible), and one that you can also continue development on with another party. You also didn’t have to pay a huge pile of money for a piece of software that doesn’t even work. You only paid for the work that was completed up until that point and because you have been reviewing and providing feedback on it in regular intervals, it should work as expected.

So, most often software projects are developed using an agile software development method. At least mine, anyway. But how does a software project typically start?

Well, it varies from company to company. By a lot. However, I can tell you how I typically approach any project so I can get enough information to start working on it and minimize accumulating any hidden cost.

After introductions I will typically move the conversation into trying to figure out what the problem is that a customer hopes for me to solve. This can be as simple as:

Our website is outdated and we’d like a fresh, modern, design and also the ability to update the site’s content ourselves.

We’d like to develop a point-of-sale (POS) system that we can tailor to our needs for improved work flow and not have to pay third party vendors a percentage

Often the discussion about the problem will lead to discovering the value that the job creates.

Value is not always, but quite often, monetary. Something that can be counted in dollars or euros saved, or gained. Other types of value be knowledge gained, boost in productivity, increase in customer satisfaction, etc.

Most of my clients want a monetary gain out of some product, so the goal is to discuss the value in terms of 

You invest some money for me to develop your application, and my goal is to enable you to get a return on that investment as soon as possible. If you do not have a plan on how you are going to get a return on your investment, you are simply going to lose money and nobody wants that.

After the problem has been identified I will ask more questions to get a better understanding of the context. Some of them will affect the planning.

What is the market for such a product (if developing one)?

Can this problem be solved using existing tools on the market?

Have you thought about marketing or advertising the product? What about licensing?

What constraints are there ie. budget, data security, privacy, technical limitations?

Is there a regulatory or a soft deadline?

What do you expect the usage for this product or app to be at launch and later?

Once I have gained more insight into the problem, I can ask about the features. Depending on the size of the product, features can either be a simple list of things a website content management system (CMS) needs to have (and the website present), or I suggest we go through a slimmer form of 

This step involves putting ourselves into the shoes of a user and thinking what the user needs to do with the product. This will give us insight into the features the product needs to have and in what order they should be built.

These features are simply the very skeleton we will begin to work with. We should not assume to be the actual user and instead gather feedback from actual users. As we gain that feedback, more stories might emerge, some stories might be dropped and some might change.

From user stories we will normally discover some 

, which simply means the quality attributes, or architectural characteristics. They will drive technical decisions later.

User stories will then be prioritised to figure out what steps we need to take to make the product actually work for users.

Within this map of user stories we can also draw horizontal lines to carve out the 

 (MVP). We can say that with the collection of these features we can release this product to the users. That is the point that the application will actually begin producing value and not be something that sits on a shelf.

That is often the initial goal. Once we have agreed on the goals, the constraints and the plan, we can start development.

Now that we have gone through the project plan and know what the problem is, and know that this is actually worth investing on, we can start development.

The most typical projects I do are split into three categories:

This list is in order from smallest type of project, to the biggest. Sometimes these categories do overlap.

I will now break these different categories of projects down to explain what they involve. Do note that no project is ever similar to another. These descriptions contain some of the most common things I’ve come across as I’ve worked on hundreds of different projects.

Websites are normally the simplest form of project. Typically I work with smaller companies or individuals who don’t have the need or budget to hire a big design and software development company to do big user experience design and development for their website.

A website project consists of the two steps that can also be iterated over throughout the project:

User Interface (UI) & User Experience (UX) design

At the start of the project I will make it clear that I am no user experience design expert, but I will still try and embed this portion into the design work. I have done user experience design, read literature and worked with professionals, trying to study their ways of working, but I do not have formal education in this field nor do I work on it on a daily basis.

However, I do not have the experience or resource to set up UX testing with users or formulate user personas.

User experience design has (in my opinion) taken over in importance over user interface design. Users want a better experience over a better look. This is why I involve this into the work, even though I might not be the greatest expert in it.

In any case, once the initial UI/UX is done, I start development. At this point of the project I have already decided the following:

The programming language. Most common: PHP and JavaScript (TypeScript)

The content management system. Most common: Wordpress or Strapi

The hosting plan. Most common: Smaller hosting provider over cloud provider.

The database solution. Most common: Relational database (MySQL).

Additional resources. This includes things such as email inboxes.

All of the things mentioned above will often surface in the early stages of the project and are based on the requested features. I will give out suggestions to the customer based on my experiences and they can give feedback on those.

In every one of these choices I try to be as cost effective as possible, and not suggest the most expensive solution out there. Normal websites have such low amounts of traffic that smaller hosting provides are capable of hosting them. Typically they offer a single server solution that includes both the ability to host the website code and a database to store data in.

In case we identify that the website is subject to high amounts of traffic, or has some features that require extra performance to complete, I will suggest other technical solutions.

This might include separating the user interface from the server side implementation and hosting that on a Content Delivery Network (CDN) which has multiple access points around the world, offering high availability to users. Also, in these cases most of the content on the site should be embedded statically onto the website and not fetched over the network.

It might also mean separating the database from the server, so it can be scaled individually and maintained separately. In this case the website can also be maintained separately.

These are all choices we have, but might not need. They are technical details that I have to think about when building a website. The more complex the problem, the more time needs to be spent to solve the problem with better solutions.

In the previous section I mentioned that one option to website development is to separate the user interface from the server side implementation. This offers additional performance, but it increase the complexity of the project, because it means building two separate applications.

The user interface application for the web is more commonly called a “

” and in a typical project is built using modern UI libraries such as React, Vue.js, Angular or Svelte, where the preferred language is TypeScript. These libraries offer an easy way to build reactive UI applications that automatically re-render when the contents of that application change.

What I have come to understand through my work, is that mobile and front-end web application development are very similar. Both are simply user interface applications that communicate with a separate 

 which is located on a server and accessible over the internet. While the development platform, framework, language and ecosystem differ, the concepts are very similar.

The most notable difference between mobile and front-end web application development is the end result. The medium through which the application is made accessible to the user. This is either a mobile device or the browser on a computer, accessed via web address.

Mobile applications can of course be developed without the need for a server-side application (also called a “

), in which case the idea is to leverage the devices own capabilities (storage, camera, location etc.)

However, in most cases you do need that server side system to, for example, store some data that the user inputs on their device, so it can be accessed later.

Insight into software development

Wow! Once again I managed to go 9 months without actually writing anything here.

What I did manage was update the entire site with a new major Strapi (CMS) version and front-end application packages. This should offer a bit more security.

Last time I posted something I mentioned I got into using the .NET ecosystem and C# language. I did manage to refresh my memory on C# and introduce myself a bit to the ecosystem, and use it to write up at least one microservice before I got yanked to another project. This time I’m working with a tech company in the US, with a new tech stack. Right now my work involves front-end development using 

, all in AWS, while previously it was React, C# and Azure.

I’ve set some growth goals this year to improve myself. While I do this continuously, this year I have specific goals in mind.

The first one is in the front-end space, to study and explore the tooling in the JavaScript ecosystem. This includes bundlers, transpilers, process runners etc. The libraries are huge and a lot of it is really complex. However I sometimes feel a bit lost working with JS/TS as part of the work is about the tooling.

Another growth goal I set was to learn golang. I already have a yearly goal of learning a new language each year. 2021 was Dart, 2022 was C#/.NET and 2023 looks like it’s going to be Golang.

This is the primary back-end language I am working with in my current project and I’ve already managed to do some work with it, and re-write my own simple 

 for on-premise servers that I’ll be using to enable continuous deployment for the apps I’m building.

Golang is an interesting, compiled, language that doesn’t contain any extra features (design decision) which makes it relatively easy to learn. My initial thoughts with it are that it seems much more lightweight than something like .NET and C# to get started with, and to develop with.

As a final goal for this year I simply have general knowledge and experience improvements in software architecture, which covers great many things that don’t all include technology, but also soft skills.

I haven’t put down the books and got through some good ones in 2022-2023. I recommend anyone in the software development space to read at least some of these.

A great book that covers a lot of different failure scenarios in big projects from an Ops point of view. A really helpful viewpoint for developers to understand that there is so much stuff in between the user and your server that can go wrong, and it doesn’t stop there. You can find cracks in your system anywhere.

Fundamentals of Software Architecture: An Engineering Approach

This was a brilliant read and I truly recommend it for any aspiring software architects. To me it helped understand that this role doesn’t just encompass a great deal of technology skills, but soft skills as well. It contains a lot of the most common architectural patterns and their trade offs.

The Pragmatic Programmer, 20th Anniversary Edition

This book didn’t really teach me anything new, but it’s one of those classics that every developer should read, preferably at the start of their career. It contains a lot of helpful tips and ideas. One of the things I did take away was the idea of investing in your “knowledge portfolio” and trying to maintain a daily tech journal.

Recommended to me by an agile coach I worked with, this book is something that team leaders should read, but keep in mind that it’s only one methodology into team building. The book contains a fictional story about a broken team that has to come together to build a foundation of trust and go through the five dysfunctions to come out better.

It’s a good read, and apparently very well known. To me it taught that trust is the foundation of any high performance team where people should speak up about issues and have candid dialog and constructive conflict, commit to decisions and hold each other accountable. All of this will results in a high performance team, as opposed to individual performance.

Extreme Programming Explained: Embrace Change, 2nd edition

On my journey to understand agility better I decided to read the 2nd edition of the good old XP book by Kent Beck. XP is still the foundations of Scrum and one, if not the only, true agile development processes out there. If you want to start learning about agile beyond the manifesto, this books should be your first read.

On my reading list I already have queued up:

Learning Test Driven Development - Saleem Siddiqui

Team Topologies: Organizing Business and Technology Teams for Fast Flow - Matthew Skelton, Manuel Pais

Just Enough Software Architecture: A Risk-Driven Approach - George H. Fairbanks

Software Engineering at Google - Titus Winters, Tom Manshreck, Hyrum Wright

(While TDD is not new to me by any means and not that difficult to tackle, as someone who’s been driven into front-end development, it still evades me a lot. I haven’t been able to instill it as an approach to back-end development since using it in the front-end is really difficult. Hopefully the book will help with that.)

Status update & recommended reading

Once again almost 8 months have passed since I posted anything in here. It’s always the same, right? You design and develop a better portfolio when you’re looking for a new job, but after that’s done you forget about it. Same with your CV.

During this time I did a bunch of stuff that I thought I’d write down here.

I read two books related to DevOps in the last few months: 

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

 touches the same subject, but from a more scientific standpoint.

These books taught me a lot. The most important thing: 

. It is a development culture within a workplace.

It is not a role, it’s not just about automation, it’s not about using a specific set of tools, it’s not just about continuous learning. It’s the collaboration of developers and operations people. Cultivating an environment where failure is not just tolerated, but encouraged. Where continuous learning and innovation is promoted, where multidisciplinary teams work together to find the best solutions embedding things like security and testing to the work from the start… among a bunch of other things.

DevOps also enables agility. Agile in itself is very simple. An agile coach I’ve been working with has told this many times:

There’s having an agile mindset and working in an agile way. Those two are separate things.

As I’ve come to understand agile better, I’ve also understood how no one should just take an “agile” framework and try to follow that with their teams. By definition these frameworks are not agile. All of them tell you to follow them exactly, or you won’t reap the benefits from them. That’s not agile. That’s the exact opposite.

Instead, what I recommend is you get to know what Lean is, what Scrum is, and build your own development process from there. Adapt to the agile mindset and start working in an agile way, collaborating, innovating, focusing on the customer value. You can do this in a number of ways.

The biggest blocker to agile in many companies is middle management. Often these people adapt an industrial mindset and want to know the deadlines, the budget and trying to hold onto a fixed plan so they can rein in those two things. But that’s not agile.

I believe that teams harboring different types of talent (so they can work an entire slice of the cake) should collaborate with stakeholders (business owners, users, customers…) to discover what problems exist and work those problems to deliver value. They should be constantly prioritizing the work, learning new things and adjusting. We’re all adults. Management should give development teams a goal to reach and trust for them to get the job done.

Getting more and more into TypeScript (but also .NET)

I’ve always been a web developer who’s mostly used PHP. I started working with it over 15 years ago and I use it to this day. But the industry has moved a little bit more towards TypeScript (JavaScript) due to its powerful ecosystem that enables fast prototyping and development.

Right now I’m working as a full stack developer on a project where my main focus for the first year was the front-end, built using TypeScript. I got rather advanced using React. I also built a lot of freelance projects using TypeScript, including building the back-end services with it, instead of PHP. What this means is I’ve been developing apps using Node.js runtime.

However, TypeScript isn’t the only language I got into deeply this year. I took a deep dive into the new .NET Core and re-familiarized myself with C#. This enabled me to start working with all the layers of the project I’m currently in. Building microservice apps using .NET Core in Azure is fun.

I’ve mostly been developing two major projects this year. I can’t get into specifics so I’ll just call these Project #1 and Project #2 while describing their problems and what I’ve been doing to solve them.

: Poor user experience using a third party ordering system, to which customers are forced to be redirected when they want to order something.

: Move the order process into the front-end application that serves the company’s website, building an integration between these two application while improving the flow.

Improving the user experience of the order process to make it more streamlined.

Developing an integration between a front-end application and a back-end system that has a poorly designed API by building a proxy API that contains business logic and some security features.

In general I would like proxy API’s (API Gateways) to be void of logic, but in this case that was impossible. As the third party system API was poorly designed, I was forced to add logic to it to make the order process work. The API also didn’t support user sessions or exchanging user credentials for a token to be used with the API. I had to build authentication and authorization into the proxy API.

: Costly third party cash register and payment terminal services.

: Build a mobile application that integrates into a payment terminal, lowering running costs and enabling more customization.

Building a mobile application for tablet devices that integrates with a Poplapay payment terminal, using Flutter. The mobile application would communicate with an Azure Functions serverless app back-end that handled the products, categories, sales and all other information.

Developing an administrative application with TypeScript and React for restaurant owners to log into and control their sellable products, categories, cash registers, payment terminals etc.

Last summer I had some spare time between projects and decided to start learning mobile development using a hybrid framework from Google named Flutter. In comparison to something like React Native, Flutter compiles itself to native languages, making them faster. The ecosystem is not the best yet, but I managed to work with the framework to build the application.

Having the realization that building an app with Flutter is much like building a front-end application in the web using something like React, made the work much easier.

For seven years I built a platform that I thought was gonna solve a big problem in the LAN event space. Unfortunately life itself happened and I found less and less time to work on the project. Then the pandemic started and events shut down. We tried to restart the project a couple of years ago, building the ticket management system and rebuilding the platform in itself, but we hit motivation issues and started to wonder if it was worth it.

In the end, solutions to this problem already exist. Building and maintaining a large scale application would take too much of our time and we decided to call quits. We also decided against open sourcing the existing work because it was too unfinished, and open source projects also need some sort of effort to maintain. None of us had the time for that.

Last 8 months

In 2020 I took upon myself to start looking up some popular books from the industry. During my career, no one has ever suggested any tech reading for me. I haven’t been interested or knowledgeable about it either. The main focus for me during the first four-five years of my career was simply to be a better programmer in general.

I took upon myself to start looking up some popular books from the industry. I wanted to become a better software engineer and architect. This lead me to write up a short list of books that I’d be interested in. I managed to read only a few of them during 2021, but I have multiple titles ready for this year!

Below I’ve listed some of the books I read in 2021 and what I’ve already read in 2022. I’ve also read some fantasy literature (like the Witcher series), but those don’t really fall into the context of this blog.

Building Microservices - Designing Fine-Grained Systems

Great book for anyone who’s interested in distributed systems or more specifically, microservices. A must for any organization that is considering a shift to then from a monolithic system. I ordered this book in fall of 2021, when the 2nd edition came out, which was a complete rewrite from the 1st edition released in 2015. 500 pages of great knowledge that stems from experience and will most likely teach you a thing or two.

Being interested in agile, this book was great lightweight reading from one of the original signers of the Agile manifesto. Kind of a memoir from Robert C. Martin of old experiences with reflections into agile from his perspective.

by Carlos Buenosvinos, Christian Soronellas, Keyvan Akbary

Having read Eric Evans’, Domain Driven Design, this was a nice continuum to it. Written with my primary language (PHP) in mind. The book is highly technical, describing how to design your application from a programmers perspective, with tons of code examples. A good read with some nice tips as I’m using DDD in a PHP app I’m currently developing.

Turn The Ship Around!, A True Story of Building Leaders by Breaking the Rules

I got interested in leadership at some point and noticed someone recommend this book in an article. It is a very nice story about empowering a submarine crew to work more autonomously in a very top-down lead organization (the navy). The idea of empowerment can be applied in any industry and will result in more performant employees, or team members.

This was one of the rare audio books I’ve ever listened to. This book describes a management style that builds upon a culture of feedback with praise and criticisms. In my opinion (and I could’ve interpreted the book wrong), the title of the book implies aggressive directness with your feedback and some people are not capable of handling that at all. You should be very careful applying this style of management without previous training in leadership or management. It does not apply to all people and you should instead identify the people you can apply it with.

Patterns of Enterprise Application Architecture

This book is more of a reference book containing a wide variety of design patterns in architecture. Some of them are quite old, but do apply in modern context. Not a very thrilling book, but maybe something you can keep on the shelf like an encyclopedia, that you can look up when you need to.

A great book that explains how to design a loosely coupled architecture. This book is something you can find any architect recommending and in my opinion it contained the best description I’ve ever read about the SOLID principles. A must read if you intend on designing application architectures.

Domain Driven Design: Tackling Complexity at the Heart of Software

One of the most important books any proper developer and architect should read. While you might not apply Domain Driven Design (DDD) in your applications, knowing this concept is a must. You will run into terminology like ubiquitous language, bounded context and aggregates in this line of work. It will also teach you a completely new perspective on how to model your application from the perspective of any domain.

This was the first UI\UX books I ever read. It is highly recommended to anyone who does user experience design. I didn’t do much design work in 2021, so I’ve already forgotten the contents of the book.

by Nicole Forsgren PhD, Jez Humble, Gene Kim

One of the most important books for any developer, architect, product owner, manager, CTO, CIO or CEO who wants to improve their technology team’s performance. This book summarizes the research behind the State of DevOps studies between 2014-2017. It explains how the authors identified the elements that make up the most high performing teams in tech and what scientific methods they used to perform these studies. I truly recommend reading this book, taking it and applying it’s teachings in your organization if you want to improve performance and actually measure it using outcomes, instead of outputs. These concepts don’t just include implementing technical solutions, but how those solutions also lead to a better culture, architecture, innovation and more.

Surrounded by Bad Bosses (And Lazy Employees)

This book mostly describes how to identify different types of bosses or employees, using the DISA model, with (in my opinion) very far end examples. It tells you how to react and communicate with them, so you can build a better working relationship. It does not contain many real life examples, which was a shame, but I did pick up a few nice ideas from it.

Diving into tech literature in 2021

2020 was something else. We can all agree on that. Most of us worked remotely. The tech industry is currently thriving. A lot of people have lost their jobs around the world. We’ve all limited our social contacts and kept distance to other people.

It was a stressful year, no doubt. I’m glad it’s behind us even though this situation hasn’t gotten any better. Now I can take a minute and reflect on what I did or accomplished during 2020. I didn’t have any specific goals or milestones. I simply did a lot of stuff which I felt like I could benefit from, in the future.

So, once again I’m listing some highlights from 2020.

In my previous blog post I talked about a toolbox we developers often keep. It’s filled with our favorite toys. Programming languages, libraries, frameworks, proprietary software etc. Often when I start a new project I look at my toolbox and pick up a few toys I think would be perfect for this project.

This year I mostly grew my front-end compartment. I tried Gatsby, Next.js, Nuxt.js, both React and Vue.js on multiple successful projects, and various packages for those two frameworks. I tried different CSS frameworks like Tailwind CSS, and UI component libraries such as Bootstrap (funny enough, I never used Bootstrap much before), Material UI, Semantic UI… But I also explored more into Node.js in a sense where I developed multiple severless solutions using AWS Lambda or built API’s using Express.js. And Docker. I used Docker on multiple projects.

The thing I learned with these was that you may seem cool just because your toolbox is big, but unless you can really profit out of it, it’s best to advertise only the toys you like most. As 2020 got further I started to notice that jumping between React and Vue.js, different state management solutions and other packages, I spent hours on each project just reading through documentation. I kept forgetting how I can set up a Redux store, or add a middleware to Nuxt.js or what kind of API some component has. The time I spent on just shifting through docs started to bother me.

The reason I kept jumping between React and Vue.js so much was simply because often projects I got hired for involved other developers, who preferred one or the other. Frameworks I could almost always pick myself, so I tried a few of them to determine which I could stick with. They all work great, but some might involve more work than others.

When working on multiple projects simultaneously, I started to prioritize work more. Even now I have a list of four separate projects listed on my whiteboard, and a todo list for each one. I prioritize work on the highest ranked projects and if I get those done, I move to the next one on the list. The bottom project is often some personal application or platform I’m building.

Prioritization is pretty basic stuff, but I’m a person who will begin to procrastinate, if I get overwhelmed with different things I should do. Writing all of them down on a list and marking them off one by one helps avoid this.

This was something I kept changing throughout the year. I tried to be cool and just use a notebook and pen, then I tried using post-it notes, but both of these fell short when you don’t have access to them unless you carry those on your at all times.

So, going digital I’ve tried different platforms for this; Microsoft’s Todo, Microsoft OneNote, Trello, Notion… I finally landed with Notion as it was really fast, simple to use, worked on multiple devices with ease and you can use it for notes, documentation and todo lists. It’s now one of my favorite tools.

I really got value out of prototyping solutions and design this year. I could quickly showcase ideas for customers and we could iterate them on a rapid pace. It helps you not commit too much and helps innovation. You can use it both for design and development.

Don’t spend too much time up front on software design

I’ve mentioned before that I started to rewrite Xerberus (my pet project) last year and I still haven’t gotten very far. I’ve been swamped with other work, but I also noticed that I spent a considerable amount of time (around 6 months) thinking about the up front design instead of just jumping on to implement it. I finally managed to put together some code late last year that fits nicely with the idea of using domain driven design (DDD) while using Doctrine ORM and GraphQL.

This week I happened to stumble on an interview on YouTube (YT), where Simon Brown & Stefan Tilkov (both of which I had watched on YT before) talk about architecture before coding. You can check it through here. I found it quite an interesting talk that also covers how too much up front design can be bad.

Based on what I learned through my own experiences, further strengthened by what Simon and Stefan discuss on the video, architecture evolves as you develop your software. Doing too much up front design will only further highlight the mistakes you made with the design later on, or it will end up hurting development, or product.

Up until last year I used to develop websites and other web related solutions using WAMP on my Windows machine, or Apache, MySQL and PHP on my Macbook. Last year, as I had to reinstall my Macbook and my PC, I decided that I won’t be installing those packages anymore. Docker should suffice. And it did.

Docker offers all the tools you need to develop your software without the need to install a database engine on your own machine. I now use Docker for every development project where I need a runtime and a database. It doesn’t take you much time to write your docker-compose.yml file which consists of maybe PHP, PostgreSQL and Node.js to run your tech stack. This comes in really handy.

Most of the websites, or applications, I now build are API first. Before 2020 I mostly completed websites using some type of templating solution offered by a framework, or by a CMS. That changed after I introduced myself properly to React and Vue.js.

I started to dig in more to Wordpress and how to use it as a REST API. From there I started looking for other CMS solutions which only work as an API and came across Strapi, which I found amazing. Contentful was also one platform that I used on a personal project, which is an API-first development platform.

This has improved my API design skills tremendously and helped me develop flexible front-end solutions with modern frameworks, quite quickly.

I also learned the importance of using metrics and in general monitoring your application for errors and status. There are plenty of tools out there to do this and utilizing them gives you visibility to your production apps. I’ve built dashboards on both Azure and AWS which help me monitor those resources. Throw in a few alerts for some metrics and you got yourself a good start in regards of visibility.

Looking back at 2020

2021 started with a rush. I got swamped with requests for different projects. Now that things have slowed dow a little, I thought I’d share some of these projects I recently worked on. Some of these would actually deserve a much bigger case study, but I might do that at a later time.

I got hired in fall of 2020 to design the logo, brand and website for a local startup named Foxcode, which was later renamed 

. The re-branding project lasted two months and during that period we kept in direct contact via Telegram. We went through several logo design iterations with the customer, finally landing in the following design which symbolizes connectivity, agility and ofcourse the company’s first initial.

Around this I built a brand guide consisting of logo specifics, colors, typography and patterns.

After this we started to plan the website. The company didn’t have many cases they wanted to put on display, so the plan was to create a small single page website which in short explained who they were, what their values are, what they do and showcase what they’ve already done. With contact information ofcourse.

I ofcourse started with wireframing and once that was cleared I moved on to the final design.

I wanted to use the same technology stack as the company itself was using, so I ended up with 

 (Node.js) for the back-end. These worked out perfectly and using Vue.js helped me expand my knowledge with the framework, while Strapi was a learning experience to a new CMS platform written in Node.js.

To make the website super fast I decided to use static site generation and fetch content at build time, so the website is basically a JAMStack solution. Since they wanted to host the website on their own server I had to come up with a way that allowed the server to pick up an event to initiate the build process again to pick up the latest content and code changes. So I spent a few hours writing an 

 that allowed it. This worked both for Github actions (code) and webhooks (content). Github actions could’ve been replaced with a proper deployment pipeline, but I felt it to be a little overkill at this time.

Due to COVID-19 the gaming event was held online, 4th - 7th of March, this year. 

 was successfully launched on the final day of January. The website uses headless 

Blog Posts

Insight into software development

Status update & recommended reading

Last 8 months

Diving into tech literature in 2021

Looking back at 2020

Recent work

Don't stop learning - Evolution of my learning process

I JAMStacked my portfolio