Gempex as MVP?

Gempex in it’s original form (

here⁠

) was estimated at 15-20 days. The main differences when developing it as a product, and then using it for gempex are, in my opinion, are:

general vs. specific (+ 5 PT)

we have to start general and build it so that it could be everything, at least in theory

then specialize to gempex

if we were to develop only gempex: we start and stay specialized

certain decisions are already made for us by the product in a (possibly unfavourable way) (~+ 10 PT)

update, deletion, ... ui/ux will have to be table (cell) specific

all user flows center around tables, instead of the gempex process

product: user lands on dashboard of tables they have access to, select the right table, ...

gempex: user lands on “rows” OR user lands on non-row tagging process OR ... based on user

we have to ((find or build) and integrate) a good table, this is a frontend and backend complexity (smooth updates for table cells are very different thant, say, smooth updated via a CRUD popup (cf. VNR)) (~+ 5 PT)

So overall I’d estimate that the overhead that is added by starting as a product is about 100 %.

Possible idea while in the process:

use airtable + self implemented flairtable + gempex frontend (still some overhead, let’s say 50-75 %)

flairatble clone can then be used to learn - as airtable backend will force us to think in way of “table API” during design and dev

if it is good to plug-and-play a different backend than airtable later on (e.g., self implemented/...)

use db + self implemented flairtable + gempex frontend (almost no overhead, let’s say 0-10 %, depending on how many decisions we make based on “airtable product”)

this is basically the product :D

will still help us solve some new challenges for product, such as user auth and building our own “table like” API (whatever we will use for visualization)

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.