MVP Monkey never got enough traction, so I shut it down. Basically, it was too hard to find anyone who wanted to buy the services.

Technologies: Multiple AI and No-code tools for rapid development, Webflow

back to the top

Preceding the more complete MVP I created a couple of prototypes using No-Code tools. The first take was to use Bubble to create a semi-working web app, mostly to explore user signup and job creation. After hitting some problems, I switched to Adalo and created a more mobile-friendly prototype.

Technologies: Nocode, Bubble.io, Adalo

I worked with a freelance designer to build a prototype of the web-based platform. She did design, html and css. I wrote the backend, converted her HTML into templates, created data models and deployed the application.

Functionality: User signup and login, job registration and listing. Automatic matching (sorting) of jobs based on the user preferences.

Technologies: Go, Google Cloud Appengine and Datastore. Standard web technologies.

Both the prototype and the MVP gave us something to test with potential users. It’s vital to get user feedback as early as possible. They also gave us something to show to investors and other potential partners.

back to the top

The development and technical aspects was a great success. We created a fast, easy-to-use app, with novel game-play and real-time attributes, in record time.

However, FFL never found product-market-fit. My opinion, and I believe the customer would agree, is that not enough effort was put into marketing and customer research.

(On this project I was a subcontractor though Shortcut and 7n)

The bakend system got reMarkable from 0 to 1 and handled the very successful launch and the first few years of operations with relatively minor improvements.

back to the top

Intolife works with restaurants, caterers and other players in the food industry. They help them cut their environmental impact. And to do it in a way that makes sense for their business. Intolife can also help them use this in their marketing. Intolife is a young and emerging company that innovates on several fronts. Few things are set in stone. As with most innovative projects, they have goals and know where they want to go, but not always how to get there. It’s important for them to always learn and adapt to the market.

The workflow used by Intolife before this project was based on Excel and manual data input. This worked fine. But it was time-consuming and limited the possibilities for interacting with third parties. With this project we created a fully customized web-based application (so called Software as a Service, or Saas) for Intolife. The goals were to cut down the time required for data entry and to automatically generate reports. We also wanted to allow for future expansion and integration with other software and services. We developed this project using lean startup methodologies. This gave us more flexibility. It also saved money by avoiding the development of unnecessary features.

The result is a web-based application that helps with data-input and report generation. This helped Intolife use approximately 50% less time on each of their projects. The application is used mainly by Intolife, but it’s also open to other partners and customers. It generates reports with 1 click. Since flexibility is important, we develop the software in phases, with their own milestones. This made it possible to quickly incorporate the lessons learned during development into the project. We meet the short-term needs while keeping the software open for future development.

The software also laid the groundwork for future expansions, and was later expanded with a REST API. This made it possible to automatically communicate with other systems. Examples are the customer’s systems and third party systems.

TV - NRK Lørdagsrevyen 9. mai 2015 (Norwegian)

back to the top

We launched this project to make it possible to integrate the Intolife web application with third parties. These third parties are typically customers and partners. They can use the API to include waste and emission data (GHG) in their own software and appliances. Using the API they can get this data automatically, without human interaction.

The API was completed and deployed to production on Google Cloud. For years It was used by IntoLife customers daily and opened up for many new possibilities. Use-cases that would otherwise involve too much human labor was made quick and easy.

Moving forward in the face of uncertainty. This project faced some challenges that are in many ways quite typical for startup projects. The first of these is the question of exactly what we are making. We had a good sense of where we were heading and why. But neither we or Intolife’s customers and partners had a concrete case in mind. We were treading new ground and the customers do not always know exactly what they want until they see it. This led to a "catch-22" situation. We needed to show something for people to understand the use-case. But, at the same time we needed customer feedback to make it in the first place. There’s no easy, magical solution to this. The way through seems to be to learn as much as possible while spending as little time and money as possible. In this case we implemented a first version of the API in cooperation with one of the customers. We will use this first version to get feedback and drive customer engagement. Improve and iterate, or build measure learn as Eric Ries puts it.

Extending an existing system does not have to be hard. There was also a perceived challenge to fit this new API "on top" of the existing code and data model. Although it’s certainly easier to start with a clean slate, this turned out to be quite manageable. The web application was made in a way that makes it easy to extend. The right level of flexibility and fairly clean and commented code makes this possible.

Writing documentation is time-consuming. The time and effort needed to write good API documentation surprised me. It was worth it though, as having this is crucial for adaptation of the API. I’ve previously experienced how missing or lacking documentation can make it unnecessary difficult to implement external APIs.

back to the top

back to the top

back to the top

Technologies: php, PostgreSQL, SQLite

back to the top

A social media engagement platform for e-merchants

Shout out Referral is a referral system for web-shops that merges e-commerce with social media. It was a new project from individuals with success from other e-commerce ventures. They had a good idea and e-commerce experience. What they needed was someone with technical know-how and developer background to help them move forward from the idea phase.

I helped draw up the technical architecture and the rest of the technology stack. After we figured out the core features, I implemented a simple prototype. The purpose was twofold: 1) to explore the possibilities and limitations of different social media providers, and 2) to show off the idea.

We ended up with a simple, but working prototype. It shows off a typical use-case for the product. We explored the different social media providers. The merging of different technologies unveiled some unexpected results. Also, we learned that authenticating with many social media providers makes identity handling challenging.

Developing a prototype taught us much and was worth the time and effort. It raised questions that should be raised sooner rather than later. There are also many assumptions made early on. These assumptions do not always hold when theory meets real life. So it’s important to check these assumptions as early as possible.

This project depends heavily on social media integrations. We soon discovered that not all the providers have equally good APIs. Also, the different providers have different policies and guidelines. Since these factors are outside our control, these limitations can not be "fixed". We must work around them. The advantage of following lean practices are clear here. We discovered these limitations early in the process, before wasting time on creating the wrong plans and unneeded code.

Using new technology can be unpredictable. There can be hidden advantages and disadvantages. Hidden disadvantages are likely more common, the advantages are often well promoted. In making the prototype we used somewhat new and unknown technology. In particular, the open source OAuth / Oauth2 library for Golang did not support App Engine. I therefore had to modify it. This was unexpected and made developing the social media log-ins ten times as time-consuming as expected. However, more often than not, the advantages new technologies bring will be worth the effort.

The prototype connects to social media like Facebook and Twitter. The full version would run in, and integrate with, a webshop.

I wrote it in Go and ran it on Googles App Engine Platform as a service (PaaS).

I really like the idea of PaaS, especially for projects that are going to grow big. I did feel the pain on working with App Engine though:

But let’s not forget the positives: * Scales totally automatically and indefinitely (If you use it correctly). This is how people often think all clouds work, but that’s almost never the case. Especially for the database / nosql / datastore.

Technologies: Google Cloud Platform, App Engine (PaaS), Go

back to the top

I wrote my own website backend and blog engine in Go, using AsciiDoc and Tachyons css . It’s a playground for testing new technologies and crazy ideas =)

https://github.com/oyvindsk/web-oyvindsk.com

back to the top

A simple, web-based and self-hosted, RSS reader I made for myself.

https://git.sr.ht/~oyvindsk/rss-web-reader

back to the top

Like most of these projects it’s partly for the usefulness, partly for learning and partly for the fun of it. This project chats with an SMTP server to find out if an email address is actually in use (works surprisingly well). Now, I’m planning to run a few million addresses through this, so even with go’s concurrency, it’s going to need more than 1 server. This is not going to be used for spam, I promise :). It has a REST API for submitting email addresses. It works, but it’s not finished.