Today, we start an adventure I aim to complete in 99 days. I want to launch a data-driven business. Often, business produce a lot of data without checking its accuracy, and then make decisions on this data. There is a direct correlation between the quality of data and the quality of decision making. However, too many organizations rely on basic system checks or manual Excel-based workflows to “spot-check” data . With qcomb, I intend to build a platform that empowers customers to implement appropriate governance control. The motto is Trusted data , Trusted insights.

Why Am I Even Doing this?

In 2023, I launched an application at my FAANG company. It was a massive success internally. We scaled it up, over time, with minimal resources. We did not pitch to anybody, customers came to us… and it wasn’t even great. This is a V3 of sorts. V1 was an MVP build in 2022, V2 is the internal application built in 2023/2024. There are a few rounds of Lessons Learnt, which I hope gives me some advantage when it comes to achieving Product-Market Fit. The goal is to make something useful that is not capital-intensive, and that we can turn into a business later.

A Scalable, Flexible and Frugal Architecture

I intend to pivot a bunch, so I am prioritizing flexibility and scalability. To achieve this, we will separate the application into 3 core elements and follow the standard pattern: Auth -> Backend -> Frontend.

• An Authentication and Authorization service that validates users are who they say they are, and enables fine-tuning of permissions and roles for business processes. The service will be based off OpenAuthJS, hosted on AWS Lambda, and using DynamoDB to manage state.
• A Backend Service that will contain the logic to wrangle data to be vended downstream to the application’s front-end. This will be writting in Python, and also hosted on AWS Lambda at least initially.
• A Frontend service that will serve the content to end-users. We will go with Tanstack Start + React as framework, with components using shadcn/ui and Tailwind CSS. We will host this using Bun on a server. I would love to stick with AWS Lambda but the state management limitations are too high to make it worthwhile here.

The Fun Stuff: Logo, Colors, and Fonts

I decided to re-use an old logo I made when I was younger, and far more creative. I added some color, re-kerred the letters, and played around with the white/black background combinations. I like that it evokes the

The same colors seem to work well for the classic square logos seen for mobile apps.

The color scheme was easy to pick. I always loved electric blue, so I put that into Coolors.co and it came up with this:

We then expanded to have a classic yellow/amber warning tone, and a green successful tone.

Overall, the core color palette is:

• F72585 Rose
• B5179E Purple
• 7209B7 Dark Purple
• 3F37C9 Dark Blue
• 4361EE Medium Blue
• 4895EF Light Blue
• 41EAD4 Turquoise
• FDE74C Maize Yellow

Fonts-wise, I am not a connoisseur so I resorted to copying other websites I like. In this case we will take inspiration from Gemini which suggests the classics: Montserrat, Lato, Roboto, etc. It’s the first time it has suggested Manrope to me so we’ll go with that to add a bit of personality of the application.

Up Next

• Set up the core stacks on servers with hellow world apps
• Set up code repositories on GitHub

The AI craze has led to many products “leveraging AI” when in reality they are just using OpenAI or Anthropic under the hood. People call these, and I loathe the word, “wrappers”. I have seen everything from AI Logo generators to AI Language training passing by AI Email Assistant and AI Photo Editors. My favourite wrapper is https://anotherwrapper.com/. Another Wrapper allows you to build your own OpenAI wrapper by leveraging its own OpenAI wrapper. Inception, amirite?

Anyway, I am not actually here to hate on “wrappers”. Rather the opposite. I think they get undeserved hate. Plenty of good products have been created by customizing existing products.

To name a few SaaS services piggybacking on cloud providers:

• OpenAI is wrapper for Azure and Microsoft
• Zoom is a wrapper for Oracle Cloud

• Netflix is a wrapper for top AWS
• Vercel is a wrapper for AWS
• Backblaze is a wrapper for AWS

But, you could also argue the same applies to hardware:

• Apple is a wrapper for Foxconn

• NVIDIA is a wrapper for TSMC

And there are even SaaS products built on other Digital products!

• Lemon Squeeze is an Stripe wrapper
• Geoguessr is a wrapper for GoogleMaps
• Namecheap is a wrapper for ICANN

And some are not digital products necessarily!

• Visa/Mastercard are wrappers for payment processors like Adyen or WordlPlay or Stripe
• VentureCapital firms are wrappers for people’s wealth

Finally, we have lots of wrappers In libraries due to the many abstractions to make certain use cases easy

• Nuxt.js is a wrapper for Vue.js which in turn is a wrapper for Javascript which in turn is a wrapper for Java/C

As a final reflection, this leads me to humans actually…Are Humans a wrapper for Mitochrondia? On a more serious note, the more you work on developing systems, the more dependencies you realize you have. Without knowing it, you are building upon several layers of abstracted code, or using services that do exactly that. Ideally, never have critical dependencies on other companies, but it wont necessarily matter. The Big Wave of cloud provider wrappers (ie: services built on AWS like Heroku or Vercel) still exist many years after being created and serve a different target market than AWS for example. It’s a wrap!

---

Picture of the Day

---

Word of the Day

Sinister is an adjective that gives the impression that something harmful or evil is happening or will happen,

There’s a sinister side to their character

Sinister stems from the Latin word “sinistra” meaning “the left-hand side”. In many cultures, the left was associated with unluckiness, weakness, or the devil. The right hand was considered the fortunate one. Bonus Fun Fact: the adjective “dexterous” which describes being skilled, comes from the Latin word “dexter” which means “right” in Latin.

This is (almost) an ode to Craig, a former colleague, friend and mentor who put up with me while travelling around the world non-stop for a couple of years while working at GSK. When I joined the team, Craig was much faster at tackling any technical problem than the rest of the team. It did not matter if he was the SME in the area or if the user had provided incorrect data to begin with. Craig would always follow the same logical mechanisms, and unsurprisingly, they always worked.

I observed what he did, and I came up with what I call the Hypothesis-Effort-Elimination (HEE) method. Craig followed a sound principle: to narrow down the problem as fast as possible, systematically. In practice, when debugging processes, systems or code, this consisted of evaluating the hypothesis that was most likely to eliminate the highest number of potential root causes with the least amount of effort. Then repeat until the root cause is found, Easier said than done.

Example Time

Let’s start by reviewing a simple example. In today’s world, processes have generally hundreds of steps end-to-end. For example, let’s imagine a product was shipped with an incorrect label. Working backwards, the label was stuck on the product by a machine. Prior to that, the label must have been printed by a different machine, which, again must have been calibrated prior to being used. For the machine to know which labels to be print, data must come from the Product Lifecycle Management software where the SKU’s Master Data is stored. The error could have happened at any point, which allows to formulate a few hypotheses, which can be ranked based on effort to evaluate them and the number of root cause they would eliminate depending on the outcome for the hypothesis.

Hypothesis	Effort	Root Causes Eliminated	Score
Incorrect label was applied on the product due to machine error	High (hard to test remotely, need to in-person support)	If correct (50%), the root cause was the machine the machine applying the label malfunctioner. If incorrect, error could be on the printer or the label master data.	Poor
The printer output the wrong labels	Medium(possible but tedious check output from printers remotely)	if correct (50%) , the root cause can be the printer or the master data. If incorrect, the root cause must be the machine applying the label.	OK
The label master data was incorrect	Low (Label Master Data is easily accessible)	If correct (50%), the error must be in the master data. If incorrect, the root cause must be downstream in either the printer or label applicator.	Good

For this first example, let’s assume we know nothing and it’s the first time we are working with this process and systems. Hence, the probability of being right is 50% for each hypothesis. Consequently, all three hypothesis narrow down the problem to the same ‘expected’ outcomes: 50% x 1 + 50% x 2 = 1.5 outcomes remaining after completing any hypothesis. The deciding factor becomes the effort, hence the lowest effort hypothesis should be completed first. If unsuccessful, the Medium effort hypothesis should be completed second to determine the root cause. Hence the scores given.

However, if we recently had previous errors with the same label applicator, this would push on the odds to 90% on the High effort hypothesis. This likely makes tackling the high effort hypotheses first a viable alternative.

Reflecting on the Hypothises-Effort-Elimination (HEE) Method

Overall, the example above is greatly simplified. In today’s tech dominated world, we are surrounded by a thousands of small services that are continuously taking to each other. However, by pairing the HEE algorithm with fundamental understanding of how servers, access controls and networking works, it is possible to establish an order to minimize the effort or time to find a solution for almost any technical problem.

I personally found the HEE algorithm super helpful in becoming a what I would call a “professional root cause identifier”. The more you practice it consciously, you will find youself formulating better hypothesis (those that eliminate more root causes with the least effort).

Over time, I found myself applying this algorithm more and enhancing it with the knowledge that work experience brings. For example, an unwritten rule I now follow is to think about simpler hypothesis that can be more easily evaluated (ie do a record count instead of a complete 1:1 validation). Similarly, it’s very rare to see systems failing intermittently and also intermittent failures are much harder to analyze generally. If a see an intermittent failure while solving a problem, I would tend to look upstream for lower-effort and more optimal hypotheses. Anyway, a book could be written about this and I cannot find much online surprisingly!

---

Picture of the Day

Koh Tao in Thailand is one of my favorite islands. I am feeling beachy today. It’s known for scuba diving and great chilled atmosphere. Everything is a short 15 min moped ride away, from beaches with small sharks and turtles to the amazing small island of Nang Yuan pictured above. Highly recommend it over Koh Phangan or Koh Samui!

---

Word of the Day

Bravado is an noun that represents bold courage, especially that shown by doing something unnecessary or dangerous with the intent to make people admire you

Larry Bird’s bravado was second to none, he was the most amusing and savage trash talker the NBA has ever seen

Aloha! Miguel here. I just finished setting up WordPress and this is the first post to check out the new default theme ‘twentytwenty five’. So far so good!

I created this blog primarily to give my thoughts some structure, celebrate successes, and document learnings. A like to think of it as a modern-day instant camera like a Polaroid. For those who know me, I tend to organize myself at very high level and that’s how I plan to grow this website. However, I guarantee every post will have three elements:

• Original thoughts
• A photograph taken by Yours Truly
• A word and its explanation, as Iexicology is another one of my hobbies

Without further ado, let’s crack on with the first item. I like to do things the hard way, so this site was not built using one of the many all-in-one blog hosting solutions. Instead, I registered a domain up through the lovely Brazilian folks @ Porkbun [$11.06/yr]. Then, I used RackNerd’s LowEndBox’s deal for a small private server to host this blog[$10.98]. I installed AlmaLinux 9 on that and followed this by installing the pre-requisites for WordPress such as Apache, PHP and MariaDB. All this software is free and OpenSource! Next, I created the database and a user for my website so it could write and read data to MariaDB. Finally, I downloaded WordPress,installed it on the server, and $22.04 later here we are!

Do I recommend this approach? Absolutely not, unless you work in tech or want to learn. However, it’s a good experience to learn. For example, I had never used AlmaLinux, which appears to be based off CentOS. Also, I had never played around with MariaDB and while setting this blog up I learnt that it is a fork of MySQL created by former MySQL developers after Oracle acquired SunMicrosystems. It inherits much of the same SQL syntax from MySQL, but like any fork over time it has diverted a bit and added interesting features making it lighter and even faster than MySQL in some use-cases.

---

Picture of the Day

Victoria Street in Edinburgh is one of my favorite streets in the world! It’s colorful, charming and almost enchanted-looking. Some cool traditional shops + Liquid Rooms which is great for a night out!

---

Word of the Day

Rollicking is an adjective used to decribe something happy, energetic and often noisy.

Arsenal are playing well! It might be rollicking fun to support them this year – said no one ever 😂😂

I love this word as it sounds great, the ‘Roll’ sound paired with ‘ick’ makes for a striking pronunciation [/ˈrɒlɪkɪŋ/]. Also, it’s speculated that it originates from merging two words: roll and frolic.