As a SaaS startup, we have very limited resources and time-to-market is always a key factor when we build our services. We have to produce awesome software that scales very quickly. To achieve this we have had to think outside the box that is the normal agile flow and come up with a way that is tailor-made for a small but highly skilled team that cooperates very well. We use an iterative process but the iteration needs to overlap for maximum speed. Instead of doing this as a dry planning chart, I thought I'll just tell the story of our Web 3.0 project (you are reading this post on the finished product 😃)
The project is mainly a design upgrade from 2.0 with a few changed features and additions so the technical requirements were pretty clear from the beginning. We simply used 2.0 as the tech base with new and improved features sprinkled on top. This kept the requirements phase short and simple.
The next step was to work on the new UX. First, we developed a general concept. With a lot of lessons learned in the backpack, we managed to agree on an overall design layout pretty fast. At this point, we have not yet decided on the design in detail. We just agreed on the general disposition in desktop and mobile versions and we tested the layouts using wireframe mockups in Figma. When we were content with the high-level structure we decided to start the POC phase of the actual implementation.
The goal was a single-page application (SPA) usable as a progressive web app (PWA). In a subsequent project, we will embed the PWA in an app shell for IOS and Android. Again, a small thing that keeps us as a small team operating at top speed. We will end up with one code base only for both web and apps allowing us to roll out changes across the board very fast.
The team members have vast experience in building web apps of this type so it didn't take long to zero in on Vue and NuxtJs. We felt that Nuxt was very lightweight, adaptable, and pluggable. React and NextJs was an option but from experience, we knew that there are so many modules and plugins that are very well crafted (and tested) in the VueJs/NuxtJs communities and that we could piggyback on, these open-source projects saved us a lot of time.
Our web hero Patrik Engborg then started on the basic structure of the web project. We followed the recommended structure of a Nuxt project to keep the need for docs to a minimum. ESlint and Husky were added to make sure we keep the code clean. Meanwhile, I prepared the Docker-build, CircleCI, and test servers and we had the app running with auto-deploy on a test environment within a day.
At this point, we can share work and test stuff very easily and the rest of Haaartland can follow the progress and give input.
The next few days consisted of scaffolding and producing placeholder components to get the basic structure and app navigation in place. In this step, we brought in Jonathan Norén which is super tidy but still a very fast developer. So Patrik and Jonathan collaborated and set the basics in order. We collaborated a lot with the UX lead Mårten Sparrman these days to make sure that we have understood the overall layout so we could be certain that the foundation is set properly.
A core fundamental in the layout is the need to support right-to-left languages like Arabic. Basically, we needed the layout to be able to flip on the X-axis depending on the user's language. Meaning margins and component flow need to adapt to the language selected dynamically.
As mainly a backend guy I started on the task of wiring up the API using the Axios client. We use vuex for state management and vuex-pathify for structured data access. Since I'm the backend techie of the bunch I set the pattern for accessing the API, how and when to cache etc. In collaboration with the others, I added functionality I knew they would need in the correct order. I started with the user API to allow for real login, continued with the feed API to be able to render basic feeds, etc. In general, I tried to give data access to the frontend guys just in time when they needed it.
At this point, Mårten had started to get the details of elements in various components ready so Patrik and Jonathan started to work their way in from the overall layout to smaller and smaller components using mockup data. We are using Tailwind CSS to rapidly be able to style components. By doing this we could get most of the functions up and when the design was ready and signed off for a component we just added that little eye candy on top. It also allowed us to make changes very quickly.
We continued to work inward with regular sync of design changes and additions. Just going further and further until we reached the smallest details and we felt content with the result.
To test the new solution we actually moved our own collaboration communities from our production environment to a staging environment running the new 3.0 code. This way we actually used the new solution very early which gave us the opportunity to fix design flaws before we put 3.0 in the hands of our users. We are users of our own platform anyways so Dogfooding turned out to be very effective for us.
Below is a time-lapse animation of the actual implementation. Basically, a visualization of GitHub commits.
Our method is different and requires a lot from the team. But it works for us!
Thanks for reading and please comment!