Meetlog: a lot has changed

I have started from scratch.

I've been intentionally refraining from writing an update for for several reasons.

First, I've started from scratch. Yes, I know, not the best decision for a product that's not validated yet. But still, you don't validate an idea, that's broken at its core.

Second, I had made some wrong decisions purely from a technical perspective. One such decision was the choice to use SCSS. As the implementation was still in its earliest stages, I had decided that it will be much easier to just start from scratch and call it a day.

And that's exactly what I did.

The "redesigned" idea

As I said, my idea was broken.

The broken aspect of it was the approach to a meeting I was proposing to the user. It was merely dull. Each meeting had several sections, where a user could enter information - like Notes section, Next steps, agenda, etc. Nothing that you couldn't do in a simple spreadsheet/doc/txt file.

The approach has bothered me right from the beginning of the development of the product. I knew there was something wrong. But I kept working on it.

Couple of days ago I had the "click".

Each meeting is basically a set of "inputs" from the attendees. As a result of the meeting, there's the meeting's "output". That was it. This simple analogy from programming brought me to the following idea:

As you can see from the screen above, the meeting now consists of an input section and an output section. The UI resembles a chat screen, but with a twist. The left side (the meeting input) is indeed a chat section, where every one of the attendees can quickly jot down an idea, thought or drop a file.

Then the twist.

Each one of the input entities can be converted to an output.

The beauty of this approach is that the meeting screen is much more flexible now. The attendee doesn't have to decide at the moment how an idea or a thought they have should be categorized. For the time being it's simply an input to the meeting. They can decide later if it's a next step, a resource that's worth it to be on the meeting's output, a note or a new scheduled meeting altogether. It's all outputs - results of the meeting, converted from the inputs.


The SCSS approach to the UI of the old implementation was a mistake.

Don't get me wrong. CSS/SCSS is awesome, I love writing it and I love experimenting with it. But compared to the tailwind way of doing UI, it's a joke.

I mean the amount of time I spend implementing a UI component is hilarious now. And making changes is a breeze.

Overall, the productivity boost of using a utility-first css framework is huge.

This allows me to move faster and experiment more aggressively.

And last, but not least, implementing dark mode is a piece of cake with tailwind. It basically costs me 1 min. more for each component to support dark mode, which is negligible, compared to the efforts I had to make to do the same thing with SCSS.

The progress

I'm happy with the progress now. It's a bit slower than I'd like it to be, but still, I've decided to play the long game here. I'm investing a bit more upfront and bet that I'll get much more ROI in the future. It's not the leanest approach, but that's how I roll with meetlog.


Popular posts from this blog

Haptic - my new side project

Building an audience is not a numbers game