My name is Seva, and I'm thrilled to share my first day as an intern at coders.fail! It was a day filled with learning, good vibes, and valuable experiences.

Right from the start, as I joined the virtual space, Joda Stößer provided me with insights into the intriguing project the team is currently working on, known as mAI.bio. What caught my attention was its ability to condense the social media platforms I provide into a digital business card, presenting me uniquely to potential followers.

Eager to contribute, I immersed myself in the project, offering feedback and brainstorming ideas. Being part of this collaborative effort felt empowering, and I cherished the opportunity to share my thoughts with the team.

Next, my training task involved creating a one-pager. For this, I worked in Versoly. It was my first time creating a web page entirely on my own. Initially daunting, I approached it with curiosity. After some trial and error, I successfully created a sleek one-page site for a conceptual "anti-vintage" clothing store. Seeing my creation come to life was immensely gratifying.

Reflecting on the day's experiences, I'm amazed by the wealth of knowledge gained in just one day. The accessibility of modern tools has truly revolutionized the landscape of coding and web design.

A heartfelt thank you to coders.fail for fostering an environment of growth and learning. I eagerly anticipate the adventures that lie ahead!

Until next time,

Vsevolod Diachenko

Just a few days ago, we noticed PayPal showing up in some of the Stripe modals for possible payment methods. Searching the interface to enable it or add it to the checkout, didn't turn up any results.

So did searching the web. Nada.

Crawling through the docs, we finally found the information we were looking for! The following docs are only accessible when logged in:

This allows PayPal to show a "join beta" form, with the account email address already prefilled.

This beta is available for Stripe customers in the European Economic Area, the United Kingdom and Switzerland.
Of course, we immediately applied and will test it as soon as possible.

Other than simplifying the checkout experience, making it easier to set up new shops and billing, being able to manage everything in one service and dashboard, is the option to use Stripe Connect with it.

This would allow marketplaces and services wanting to split a payment between different fulfillers, to support PayPal payments as well.
In the past, supporting PayPal meant building a custom payout system.
No more!

Since updating to Ghost version 5.22.10 the following error message popped up when opening any of the admin post lists/views:
Request not understood error, cannot list posts. Could not understand request.

• Testing a bit around and downgrading showed, that the first affected version is 5.21.0.

• Version 5.22.0 through 5.22.10 are also affected.

• Version 5.20.0 is the last unaffected one.

Steps to Reproduce

1. Install Ghost version 5.22.10

   • Either through an update or a clean install.

   • It doesn't matter if there are already posts created or not.

2. Open the Ghost admin backend

3. Open one of the post lists/views.

Relevant log / error output

Browser HTTP Request

URL

Browser HTTP Request URL:

/ghost/api/admin/posts/?formats=mobiledoc%2Clexical&limit=30&page=1&filter=status%3A%5Bdraft%2Cscheduled%2Cpublished%2Csent%5D

Response

Browser HTTP Request Response:

{
  "errors": [
    {
      "message": "Request not understood error, cannot list posts.",
      "context": "Could not understand request.",
      "type": "BadRequestError",
      "details": null,
      "property": null,
      "help": null,
      "code": "ER_BAD_FIELD_ERROR",
      "id": "c1801070-6273-11ed-8e21-c102c3d5082c",
      "ghostErrorCode": null
    }
  ]
}

Server

Server/Backend log entry:

{
  "name": "Log",
  "hostname": "**REDACTED**",
  "pid": **REDACTED**,
  "level": 50,
  "req": {
    "meta": {
      "requestId": "88c4655a-1137-40fe-b3e4-9c2c85456430",
      "userId": "1"
    },
    "url": "/posts/?formats=mobiledoc%2Clexical&limit=30&page=1&filter=status%3A%5Bdraft%2Cscheduled%2Cpublished%2Csent%5D",
    "method": "GET",
    "originalUrl": "/ghost/api/admin/posts/?formats=mobiledoc%2Clexical&limit=30&page=1&filter=status%3A%5Bdraft%2Cscheduled%2Cpublished%2Csent%5D",
    "params": {},
    "headers": {
      "host": "**REDACTED**",
      "sec-ch-ua": "\"Google Chrome\";v=\"107\", \"Chromium\";v=\"107\", \"Not=A?Brand\";v=\"24\"",
      "dnt": "1",
      "sec-ch-ua-mobile": "?0",
      "app-pragma": "no-cache",
      "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36",
      "content-type": "application/json; charset=UTF-8",
      "accept": "application/json, text/javascript, */*; q=0.01",
      "x-requested-with": "XMLHttpRequest",
      "x-ghost-version": "5.22",
      "sec-ch-ua-platform": "\"macOS\"",
      "sec-fetch-site": "same-origin",
      "sec-fetch-mode": "cors",
      "sec-fetch-dest": "empty",
      "referer": "https://**REDACTED**/ghost/",
      "accept-encoding": "gzip, deflate, br",
      "accept-language": "de,de-DE;q=0.9,en-GB;q=0.8,en;q=0.7,en-US;q=0.6,en-DE;q=0.5",
      "cookie": "**REDACTED**",
      "sec-gpc": "1",
      "x-forwarded-proto": "https",
      "x-forwarded-for": "**REDACTED**",
      "x-forwarded-host": "**REDACTED**",
      "x-forwarded-server": "**REDACTED**",
      "connection": "close"
    },
    "query": {
      "formats": "mobiledoc,lexical",
      "limit": "30",
      "page": "1",
      "filter": "status:[draft,scheduled,published,sent]"
    }
  },
  "res": {
    "_headers": {
      "x-powered-by": "Express",
      "vary": "Accept-Version, Accept-Encoding",
      "cache-control": "no-cache, private, no-store, must-revalidate, max-stale=0, post-check=0, pre-check=0",
      "content-type": "application/json; charset=utf-8",
      "content-length": "279",
      "etag": "W/\"117-g2i2/Ll57qIbCQdZFnvScK7Hl3c\""
    },
    "statusCode": 400,
    "responseTime": "30ms"
  },
  "err": {
    "id": "c1801070-6273-11ed-8e21-c102c3d5082c",
    "domain": "https://**REDACTED**/",
    "code": "ER_BAD_FIELD_ERROR",
    "name": "BadRequestError",
    "statusCode": 400,
    "level": "normal",
    "message": "Could not understand request.",
    "stack": "Error: select `posts`.*, (with `k` as (select `member_id` from `members_subscription_created_events` where posts.id = members_subscription_created_events.attribution_id union select `member_id` from `members_created_events` where posts.id = members_created_events.attribution_id) select count(*) from `k`) as `count__conversions`, `posts`.*, (select count(distinct `members_click_events`.`member_id`) from `members_click_events` inner join `redirects` on `members_click_events`.`redirect_id` = `redirects`.`id` where posts.id = redirects.post_id) as `count__clicks`, `posts`.*, (select COALESCE(ROUND(AVG(score) * 100), 0) from `members_feedback` where posts.id = members_feedback.post_id) as `count__sentiment`, `posts`.*, (select count(*) from `members_feedback` where posts.id = members_feedback.post_id AND members_feedback.score = 0) as `count__negative_feedback`, `posts`.*, (select sum(`score`) from `members_feedback` where posts.id = members_feedback.post_id) as `count__positive_feedback` from `posts` where (`posts`.`status` in ('draft', 'scheduled', 'published', 'sent') and `posts`.`type` = 'post') order by CASE WHEN posts.status = 'scheduled' THEN 1 WHEN posts.status = 'draft' THEN 2 ELSE 3 END ASC,CASE WHEN posts.status != 'draft' THEN posts.published_at END DESC,posts.updated_at DESC,posts.id DESC limit 30 - Unknown column 'posts.id' in 'where clause'\n    at **REDACTED**/versions/5.22.10/node_modules/@tryghost/bookshelf-pagination/lib/bookshelf-pagination.js:259:27\n    at Packet.asError (**REDACTED**/versions/5.22.10/node_modules/mysql2/lib/packets/packet.js:728:17)\n    at Query.execute (**REDACTED**/versions/5.22.10/node_modules/mysql2/lib/commands/command.js:29:26)\n    at Connection.handlePacket (**REDACTED**/versions/5.22.10/node_modules/mysql2/lib/connection.js:456:32)\n    at PacketParser.onPacket (**REDACTED**/versions/5.22.10/node_modules/mysql2/lib/connection.js:85:12)\n    at PacketParser.executeStart (**REDACTED**/versions/5.22.10/node_modules/mysql2/lib/packet_parser.js:75:16)\n    at Socket.<anonymous> (**REDACTED**/versions/5.22.10/node_modules/mysql2/lib/connection.js:92:25)\n    at Socket.emit (node:events:513:28)\n    at addChunk (node:internal/streams/readable:315:12)\n    at readableAddChunk (node:internal/streams/readable:289:9)\n    at Socket.Readable.push (node:internal/streams/readable:228:10)\n    at TCP.onStreamRead (node:internal/stream_base_commons:190:23)",
    "hideStack": false
  },
  "msg": "Could not understand request.",
  "time": "2022-11-12T10:21:22.564Z",
  "v": 0
}

GitHub issue:

Workarounds, tips and hints

The Ghost CLI removes old versions while updating. In the easiest-to-find search results, it is documented or mentioned, that the last 5 versions are kept, e.g.:

That includes the most current version, that was likely just installed through the update. So only 4 "old" versions are kept.

This has been changed in version 1.15.0 with no mention in the short changelog through the commit badb662, so I just missed it.

Since then, only the 2 most current versions are kept, because of disk space concerns: #201 (comment)

As this includes the most current version, only 1 "old" version is kept.

Checking the code, it seems like the version removal feature only takes Semver sorting into account:

Lines 149 to 164 of update.js:

async removeOldVersions({instance}, task) {
    const semver = require('semver');

    const versionDirs = await fs.readdir(path.join(instance.dir, 'versions'));
    const versions = versionDirs.filter(semver.valid).sort(semver.compare);

    if (versions.length <= 2) {
        task.skip();
        return;
    }

    const promises = versions.slice(0, -2)
        .map(version => fs.remove(path.join(instance.dir, 'versions', version)));

    await Promise.all(promises);
}

It does not check for the currently active or just installed version or sort the version by last use.

This leads to the unfortunate scenario, of just having downgraded to an older version and Ghost not being able to start, as it was promptly removed again and the current symlink points to a version directory that does not exist.

Steps to Reproduce

1. Have a Ghost install with the 2 most current versions installed

2. Run ghost update with an older version, like ghost update 5.2.0 --force

3. Observe, that old Ghost versions are being removed

4. Try to start Ghost and see errors or check the current symlink pointing to a version directory that does not exist.

ghost update 5.2.0 --force CLI command log:

$ ghost update 5.2.0 --force

Love open source? We’re hiring JavaScript Engineers to work on Ghost full-time.
https://careers.ghost.org

Running in development mode

✔ Checking system Node.js version - found v16.18.1
✔ Ensuring user is not logged in as ghost user
✔ Checking if logged in user is directory owner
✔ Checking current folder permissions
✔ Checking memory availability
✔ Checking free space
✔ Checking for available migrations
✔ Checking for latest Ghost version
✔ Release notes were not found
✔ Downloading and updating Ghost to v5.2.0
✔ Linking latest Ghost and recording versions
✔ Removing old Ghost versions
ghost update 5.2.0 --force  15.27s user 9.01s system 137% cpu 17.708 total

Possible solutions, not mutually exclusive

Always keep the current active version

Add a check, to never delete the currently active version or exclude it from the removal feature outright.
The latter would increase the number of kept versions to 3 if the feature is not adjusted for that.

Add a config option and/or CLI flag for the number of versions to keep

The change from keeping 5 versions to just 2 went by unnoticed, and it would have been great if users/admins could define the number themselves. Everybody has different infrastructure, storage requirements and rollback needs.
This would be great as a config option as well as a CLI command flag.

Keep the last active versions

Instead of just keeping the latest versions according to Semver, it would be cleaner to keep track of the active and used versions. People might not just upgrade to newer versions, but jump around.
Keeping previous versions according to the history of used versions would simplify things a lot.

GitHub issue:

Workarounds, tips and hints

Make sure to have a "free slot" for keeping versions available. With only 2 versions being kept, this means removing all (typically 1) but the most current one. That way, the feature won't be triggered, and the downgrade version is not deleted.

The Ghost CLI allows for updating (and installing) specific versions/tags of Ghost. It is possible to provide them with v as a prefix, or without, as well as only providing the major version or the major and minor versions, omitting the patch version.
If the minor version is a multiple of 10 (10, 20, ...), having at least 2 digits and ending in 0, the wrong version gets installed. The 2 digits are split, and the first is used as the minor version and the 0 as the patch version.

Steps to Reproduce

1. Have a Ghost install
   Preferably, with version <5.20, so the --force flag doesn't need to be used

2. Run ghost update and provide a specific version, that has a minor version of a multiple of 10 and don't provide the patch version, like ghost update 5.20

3. Observe, that Ghost version 5.2.0 is getting installed

CLI command ghost update 5.20 log:

$ ghost update 5.20

Love open source? We’re hiring JavaScript Engineers to work on Ghost full-time.
https://careers.ghost.org

Running in development mode

✔ Checking system Node.js version - found v16.18.1
✔ Ensuring user is not logged in as ghost user
✔ Checking if logged in user is directory owner
✔ Checking current folder permissions
✔ Checking memory availability
✔ Checking free space
✔ Checking for available migrations
✔ Checking for latest Ghost version
✔ Release notes were not found
✔ Downloading and updating Ghost to v5.2.0
✔ Linking latest Ghost and recording versions
✔ Removing old Ghost versions
ghost update 5.20  15.27s user 9.01s system 137% cpu 17.708 total

GitHub issue:

Workarounds, tips and hints

Specify the full version including the patch version, like: ghost update v5.22.10

Instead of providing a fully automated and integrated marketplace, we'll either provide the source files or compiled WASM assets to upload and update yourself.

Of course, providing them in a shop built on Swell: https://www.swell.is/

All our other approaches, a public Marketplace for all vendors, automated deployment, integrated configuration, multi-worker configuration and automated share distribution.

This will be the shortest amount of development to get to a magnetizable product and the first version of our worker shop and workshop.
In the spirit of getting as quickly to v1 and building atop it, we decided to go with this approach first.

With multiple registered Cloudflare Workers, just one with the more specific route matcher will process the current request. This prohibits any chance of having multiple workers process the request.
This is needed, especially when using highly specialized workers, which optimize the content of the requests. Like caching and image optimizations.

This is hindered by the fact, that the obvious solution of having one router worker which proxies the original request to the first worker and sends its response and the modified request to the subsequent worker, following the same logic for any additional workers, just doesn't work.

Cloudflare does not allow for sending the response of the previous worker to the subsequent one but forwards the original request.
To solve this, some workarounds need to be used to make it possible.

We've managed to find multiple solution approaches, at least one of which already showed promising results and works. There is still room for improvement, and try to find the cleanest approach.

Obviously, every worker, every request, and every additional step adds latency and makes the request-response take longer to reach the client. To prevent this from happening to each request, this system needs to heavily rely on a good caching strategy.

To be able to make this approach work, there needs to be a proper setup for the worker to capture all the routes of the other workers. It needs to be configured to be able to proxy to all necessary workers.

We've already started building an interface to manage those workers and routes, to extend the possibilities offered in Cloudflare's web interface. The possibility to integrate into the future worker marketplace is already set up and conceptualized.

Like with the last pivot to a worker marketplace, the development complexity is much higher than originally planned for our first ideas. This won't keep us from trying, might lead to another pivot.

Stay tuned!

If possible, we schedule them during vacations or public holidays, to spend more time on the project.
It helps to be working at the same company, with the same clients and projects, as well as work mentality and benefits. This reduces the disconnect during the day and helps us stay in sync.

Our first boot camp ended up being 7 days after we scheduled it up for up to 2 weeks. Other responsibilities came up and the intensity of the first days made us need to take a breather.

We spent most of the time setting up the basics, finding the name for our project, registering the domain, setting up our tools like Notion, Stripe, Swell and Google Workspace and email as well as rating our business ideas.

The rest was getting into the thick of Cloudflare Workers' technical details, Swell setup and customization and discussing our pivots from idea to idea after finding roadblocks in our original approach.
During this, we connected with the communities of the chosen tech stack, started some discussion and collected some contact details.

We are looking forward to our second boot camp, which will not be held in the same country, but digital slowmading together.

Overall, it does make sense. They scale well, there is near to no upfront financial investment, they are fairly easily built with no frontend necessary, target infrastructure and thus are not dependent on user-generated content.

After the first worker was already built and ready, we realized the originally announced Apps with Workers feature, which would have allowed using the Apps marketplace to sell bundled workers, surprisingly never got out of the closed beta.
It was even actively closed as noted in the docs:

Cloudflare's App Workers Beta is now closed. We are no longer accepting new apps that contain Workers scripts to focus on improving the Workers development experience.

That is very atypical for Cloudflare features that typically go to general availability after the closed and then open beta. A more detailed explanation was posted on the forum. Coupled with a promise to be working on another solution.

Learning all this, a defeated feeling set in, and we felt it was the first big lesson of our journey. Not the idea being bad, not having no customers, but our assured monetization platform not existing at all.
Scrutinizing ideas and vetting and validating monetization options, will become a bigger part of the process.

Luckily, accepting this small loss, a few minutes later the next idea formed: Our own Worker marketplace!
Offering a place for everyone, including us, to sell their workers.

Of course, this idea would be much bigger and more complex, crushing our limitation of only spending a month on any specific idea.
Being confident in this idea, we accepted this and were willing to make an exception.

Especially after putting our heads together, and jotting down the first version of the concept. Building on our e-commerce development experience, pretty wide knowledge of possible technologies and tools and the willingness to try something new.

The main advantage for us here was Swell e-commerce SaaS:

They offer loads of flexibility for developers, solid docs, flexible API, switching out the checkout completely and the option to change the database models for every entity, instead of just using meta fields / custom fields like competing options.

Landing page on why Swell makes sense for building marketplaces: https://www.swell.is/for/marketplaces

A few things stood out:

1. A great pricing scheme for startups, where you don't pay anything until you earn the first buck and the ability to switch to a more profitable plan later on when the revenue is big enough.

2. Supporting the frontend stack out of the box and hosted, which we wanted to use anyway: Nuxt
   As well as allowing you to host the headless frontend yourself, like on Cloudflare Workers.

3. A preexisting guide to build a marketplace with Swell, from Swell itself:

This guide is based on Stripe Connect, which allows easy distribution of revenue shares to multiple partners. It simplifies the booking immensely, as it immediately transfers the appropriate share to each vendor.
Meaning, we would never have that money in our accounts and don't need to deal with it.

Of course, every idea comes with its new challenges. This time, it was the limitation of Cloudflare Workers to have only one Worker active on each request route at each given time.

Having some client prospects in mind, that could benefit from at least one of our Worker idea, while already using a Worker for caching, this limitation was to be circumvented.

As hoped, this led to the next idea: A Worker router!

Going through the first batch of ideas, explaining them to each other and trying to rate them consistently, it became clear we would be there a while.
We took a few steps back and started with our rating rubric. We defined 5 areas and assigned a value from 1 to 5 to each of them, with 5 being the best and 1 being the worst.

Financial potential

What kind of MRR can we expect?

1. no monetization potential

2. 0 to 200 bucks per month

3. 200 to 2k bucks per month

4. 2k to 4k bucks per month

5. over 4k bucks per month

Feasibility

How long does it take to build?

1. not feasible for us at all

2. over a month

3. 2 to 3 weeks

4. 1 to 2 weeks

5. under a week

Automation potential

1. every purchase requires repeated effort

2. every customer requires effort for onboarding in addition to constant content management and creation

3. no customer onboarding, but constant content management and creation

4. no customer onboarding, but some manual effort on occasion, like support rare requests

5. no product content management and no customer onboarding

User-generated content independence

How much of the value is based on user-generated content?

1. the whole product value is based on user-generated content

2. the ratio of independence to user-generated content is 25 / 75

3. the ratio of independence to user-generated content is 50 / 50

4. the ratio of independence to user-generated content is 75 / 25

5. the product value is not based on user-generated content at all

Marketing potential

1. the niche is difficult to define and hard to capture

2. the in-between state, as defined by a gut feeling

3. the niche is neither difficult nor simple to define and neither hard nor easy to capture

4. the in-between state, as defined by a gut feeling

5. the niche is easily defined and easy to capture

Not all the values were easy to associate with real word representations, especially with low to non-experience launching a bootstrapped startup. Finding a common rating rubric, that we both agreed on and would result in the same values if rated by either of us.

It took us an entire day to go through all of them, getting sidetracked often while getting into heated discussions by our enthusiasm for an idea or an argument about whether we want to pursue something.
Keeping each other accountable to only spend a few minutes on each rating, disregarding our drive for perfectionism, helped immensely.

At the end of the day, we had a few ideas with an average score of over 3 or even 4. Most of them relied on Cloudflare Workers, making them mostly easy to build, low cost, extremely scalable and easy to install.
They would be the first ideas we would build.

Our previously defined framework provided some inspiration in which direction we wanted to look for ideas. Immediately looking for ideas that scale, are minimal to be built in 2 weeks, don't rely on user-generated content, are easy for us to market and have a real value proposition.

After our meetup at the About You Pangea festival 2022, we stayed in contact and had a lot of calls every few days. We migrated all of our ideas into Notion and typed all of them down as soon as they came to mind.

Quickly, we realized there were some idea groups and categories, so we created a second database named "Inspirations" and grouped our ideas under them.
Over a few weeks, the list grew to over 70 entries.

Surprised by the sheer amount, we realized our constant exchange as well as being exposed to different technologies and mediums in our day-to-day lives kept our brains fresh and brainstorming became easy.
It is a real skill that can be learned, and you get better at it when trained.

It is very important not to get fixated too much to not block yourself. Take enough time to think and talk, as well as enough space to write things down.
Be sure to get enough sleep, food, movement and sun. Every bit helps.

We tried integrating the setup in between coding and brainstorming sessions. Due to a lack of time and interrupting the process often to deal with more important things prolonged the process immensely.

We aimed at finding tools that would come at no cost for us for now and would allow us to grow into their paid versions, as soon as we had recurring revenue.

Notion

Documentation and workflows

Notion is a great tool for notes, documentation, databases, tasks, calendars and just generally organizing the knowledge and processes of a team.

Learn more about Notions Startup credit program and apply

Cloudflare

Domains, infrastructure and analytics

Working with Cloudflare on the regular at our employer, it was a no-brainer to use it to improve our infrastructure or even base service completely on it with its workers.

Especially, since most services are completely free or have a very generous fair-use / free limit.

Even providing a registrar service that supports more and more TLDs which charges transparent prices of the main registrar of that domain, we used it to buy most of our domain.

In addition, hosting static pages on Cloudflare Pages is completely free of charge and the limit of 500 CI builds per month won't be reached for a long time.

Cloudflare also provides an analytics feature that can be automatically installed through the proxy feature or a JavaScript snippet. Even though we want to tinker with open-source and self-hosted services like Plausible and Fathom, for now, we can start easily for free and with no additional setup effort.

Bitwarden

Shared passwords and MFA/2FA

Bitwarden is an open-source Manager that is free for most use cases. The free version allows for unlimited personal use and allows for the creation of one organization with 2 members, for sharing and collaborating entries and logins.

Even though the generation of 2FA/MFA codes is a paid feature, the free version allows you to save the base string to enable that feature later or share the string with all members to enter them into their own 2FA/MFA apps.

Google Workspace

Email and data storage

Email is one of those issues you don't want to deal with yourself. Hosting your own email server can be painful, time-intensive and quite difficult to get right. We knew from the start this to be a topic we were not supposed to be cheap with.

Google Workspace was an easy choice, as it is cheap, offers a lot of features, integrates well on mobile and is already known to us.
To begin with we didn't need personalized accounts, so we only created on users and added email aliases with our names to it.

Twitter

Work log and engagement with the community

Twitter is very actively used by the SaaS, bootstrap and #buildinpublic community as well as a lot of developers. We will use it to document our progress and engage with the community.

@coders.fail on Twitter

Stripe

Getting paid and marketplace automations

As one of the biggest payment processors and gateways, we knew we needed an account. Especially, since we were interested in building marketplaces, which is much easier to do with Stripe Connect.

PayPal

Getting paid and paying

PayPal has become a main staple of online payments and cannot be ignored. Not only for receiving payments, but also for paying for services needed in our infrastructure.

Servers

Hosting and testing ground

Cloudflare Workers and Pages being great for static content and frontends, we needed a place to host our backends and to play around. A lot of cool services rely on Docker containers.

The big hosters offer startup credit programs, but we decided to start with our already available private resources and migrate to a hoster later.
This makes sense especially, as applying to the credit programs is only allowed for new customers, not existing ones, and we wanted to deploy our blog and site first.

Chartmogul

Recurring revenue analytics and public data

To properly #buildinpublic we wanted to display our MRR (Monthly Recurring Revenue) in our Twitter bio as the location, like so many others. The main service used for this is TweetSync in connection with ChartMogul, which can pull in data from Stripe.

GitHub

Code, project management and sponsors

As the biggest service for Git repositories, GitHub was the obvious choice. Wanting to use GitHub Actions for our CI in the future, cemented that decision.

Creating an organization is free now and allows us to keep private repositories, as well as public ones.

The GitHub sponsor program, similar to Patreon or similar services, allows for receiving direct support.

bunq

Banking, account and credit card

bunq is a Dutch bank built by developers. It provides great features, like 25 subaccounts and cards as well as local bank account numbers (IBAN) for some European countries as well as holding money in different currencies.

It provides a lot of benefits to those who enjoy technology and know what should be possible with it, even in the banking sector.
It provides APIs for automation, etc.

As we were already paying for private accounts and Germany allows freelancers to use their private bank accounts for their work, we started out using it.
Creating a free (limited) business account is easy and we can switch to more features are soon as we deem it sensible to create our business entity.

Link to directly support us

Affiliate link to sign-up and give us 10 trees

Having just found and defined our vision and framework, we needed a place to put down all our thoughts, decisions, workflows and ideas.

Being already familiar with it from personal use and at the company we are employed at, we started with Notion. The free version for teams and collaborative allows for 1k blocks.
We were lucky and Notion forgot how to count for the first weeks of our usage, so we could exceed that limit, which we did in a matter of days.

Very quickly we collected ideas for names and domains, actual business ideas, to-do lists and boards as well as our vision and workflows.

Notion's ability to display entries in a database in multiple different ways (list, table, board, calendar and timeline) as well as allow for different filters and sorting settings on each view, helped us keep track of everything.

Even better, the new display of integer fields as progress and percentages as well as the formula property, helped us immensely whilst rating our business ideas. We could calculate an average, sort them by that value and filter out entries that are currently not relevant.

Startup Credits

Notion is great but can be too expensive for people just starting and aiming to keep their cost down as much and long as possible.
Notion helps out with this by providing a startup credit program to which anyone with a website can apply. It doesn't even have to be set up in English.

They grant $1k in credits as a maximum, but lower amounts are possible as well.

To learn more about Notions Startup credit program and apply, visit the dedicated landing page: https://www.notion.so/startups

Workarounds, tips and hints

If you are still missing a website or valuable content, there are other ways around the limitations.

When working with a team, create a central account that you all use together to avoid the limits placed on collaborative workspaces. To associate tasks with members of your team, create a separate "team" database and work with relations.

This has the additional advantage of allowing to reference users who are not yet onboarded to Notion and external partners that will never be in Notion as well as retroactively noting down team members who are not part of the Notion team anymore.

In our time during the About You Pangea Festival 2022, we came up with our vision for:

• co-creation

• our projects and startup

• the way of working and approaching ideas

• the contents of our ideas

Instead of starting with one idea, as many do, it was more important to us how we were going to work and what our day-to-day would ideally look like. Especially since we both had some experiences with freelance work and bootstrapping startups that didn't work out the way we wanted them to.
So a different approach was needed to succeed someday.

The way to success would be lined with lessons learned, disappointments, and failures, that was clear to us. So we decided to embrace the lessons it would provide and make it a point to fail rapidly, repeatedly, openly, publicly, honestly, and confidently.
And then learn from our results, identify our mistakes, correct our approach, iterate, and improve.

Each of the failures would allow us to create content about it, allowing others to learn along with us and get to their goal faster. The decision to #buildinpublic was easily made and would force us to get more comfortable with failure culture, kick-start personal growth and hold each other accountable with open communication.

To do so, we needed our name and presentation to reflect and make people quickly understand. We went through quite a few iterations. Very quickly, we fell in love with the idea of having 2 domains: 1 with the .fail TLD and one with .win

The main ones with win/fail TLDs in the running were:

1. coders

2. decode

3. next

• replay / incremental / iterative

• simple / mvp / nevermind / poc / bootstrapped / value

• endless / constant / many

• loud / noisy

• humble / confident / bold / graceful

• planned / certain / upcoming / calculated

But also others like: fuckup / instant / quickly .build

In the end, we decided on the name that we both could associate with, where both TLDs were still available, and where Google keywords would not be highly competitive.

Our vision framework

The rough outlines of our approach ended up being the following:

In the past, we kept changing and improving the concept of an idea over and over, kept working on it for a long time, and never really launched and validated it.

People will start using it when I get it to that perfect point and feature set.

So we limited ourselves to having a rough version 1 ready after 2 weeks. Just spend after-work hours and weekends on it.
Preferably, we would spend that time together in one location to improve our communication and keep our focus and motivation.

Getting the idea to a launch state with working out the last kinks, after successfully building the core, would take a bit more time. So we gave ourselves 2 additional weeks to do so, get people excited for it, and prepare the monetization.

This time could be very well spent apart and wouldn't require us to be in the same location. Giving us a bit more freedom and focus on the task at hand.

After the conclusion of the month, the idea needs to be fully launched and include a monetization feature. Ideally, we would already have the first purchase at that time, giving us an idea if people would like to pay for it.

With this approach, each idea would not take more than a month to get launched, allowing us to rapidly iterate on things we would like to improve on.

Being passionate about the work we do at our company and web tech and development, we discussed some future ideas with our colleagues to advance the stack of the company, maybe fill the vacation fund or start completely new ideas.

Starting to talk about it on our boat trip, we continued to discuss ideas, paths forward and how to approach it throughout the way back in airports, planes and trains.

The next time, both of us met up to advance our ideas and develop our approach was at the About You Pangea Festival 2022. It gave us some distance from the rut of our daily lives and gave us a space to freely think about new ideas.
Both of us had worked freelance before with varying success and satisfaction and wanted to improve upon it.

Our Tweet about meeting up at the About You Pangea 2022 festival for brainstorming

By meeting up beforehand, staying 4 days at the festival and having another day after, we could spend some real time together. It gave us enough time to switch it up between brainstorming sessions, swimming, eating, drinking, dancing and chilling.
A lot of different influences from music, artists, cultural events, sports and just people in general allowed us to switch it up to kick-start our creativity.

Our desire to start bootstrapping startups together was not born of a singular business idea nor a dissatisfaction with our jobs or the work we did. But from a drive to grow as people, learn new skills, a belief to thrive as freelancers and entrepreneurs, inspired by other #buildinpublic bootstrappers. Realizing, that getting paid by the hour doesn't provide a lot of opportunity to scale it and very few companies allow one to contribute to better processes to allow for internal optimization and automation, never mind profiting from it yourself. Mostly the latter.

Our tweets about our activities and brainstorming at the About You Pangea 2022 festival

Being interested in working on bigger projects, open-source, non-profits and selflessly improving the world for everyone without getting paid, we longed for a passive income that would allow us to invest the necessary time.

It became clear to us, that we needed an approach to building, launching, validating, marketing and monetizing projects and startups in a way that would get us to the goal the fastest.
The immediate goal would be to get to 2k € MRR, 1k € for each of us, giving us a certain amount of freedom to reduce our working hours in typical jobs and focus more of our time on creating the next one or expanding an existing one.

They needed to be very low-maintenance and automatically scalable until the time when monthly revenue would allow us to spend time on them regularly.

To find other people talking about #buildinpublic check:

• https://twitter.com/buildinpublic

• https://twitter.com/search?q=%23buildinpublic