Skip to main content
Marcel Krčah

Embarrassingly simple proof of concepts

Published on , in

The start of a project, I've noticed, often determines the pace for the whole project. I discovered that what works well is to start with a proof of concept that is embarrassingly simple. "Embarrassingly simple" clarifies what to expect: a half-baked barely-working solution. "Embarrassingly simple" is also kind of funny when said out loud, and it sets a good mood within the team. To me, a recovering perfectionist, "embarrassingly simple" also crystalizes what to build and what to exclude.

Here's an example: We needed to integrate system A with system B by periodically calling the APIs. To make the proof of concept embarrassingly simple, we excluded tests, devops and monitoring, we ignored edge cases and unhappy paths, and we were pretty relaxed about code quality.

We ended up with a manually-triggered script that reached out to system A, extracted one field from one object, and stored the field in system B. We could have run API calls manually, but a bit of automation is a nice touch for demos. We also aimed for high impact, so we asked which object and which field have high priority.


Cutting corners where possible, the concept was delivered quickly. Clients like that, it turns out. We also learned a ton about the systems:

We reached the first deliverable, we set the pace, and the client is satisfied. Now, it's about keeping this up through the middle to the end of the project.

This blog is written by Marcel Krcah, an independent consultant for product-oriented software engineering. If you like what you read, sign up for my newsletter