The 12 Startups in 12 Months (Open Source Edition) challenge that I started July 1, 2022 is over and this is the wrap up post summarizing my thoughts. When looking at other challenges, it was often disappointing to not see any final thoughts so I wanted to make sure I concluded everything in a wrap up post for anyone else considering taking on this challenge.

I completed 2.5 projects during the 12 months, but I wanted to complete the third project before writing this post. The third project was officially launched in January 2024.

1. Introduction
2. Good
3. Bad
4. Recommendations
5. What I Learned
6. Next Steps

Introduction

Before starting the challenge, I had a lot of ideas for projects, but wasn't sure what I wanted to focus on. I also have never been good about broadcasting what I'm working on. I thought undertaking the challenge would force me to focus on building and stop trying to analyze what I wanted to build. I thought it might also help me build an audience because it would give me a reason to post more on social media.

The funny thing is that I think that those goals had both major successes and major failures. There was a bit of good and bad. Let's go through them below.

Good

There were many good results from the challenge. It forced me to put my head down and build. I tend to think through projects 10 steps down the road to see if I really want to pursue a project. You'll never be able to forsee all the issues that will arise so forcing me to just build and not analyze was very productive and helpful.

I've been a full-time freelancer since 2005. The goal has always been to be able to have my projects bring in enough income to support myself, but juggling freelancing and building your own projects is very difficult. I've found that I often spend a lot of energy and time on client projects and have very little left over for my own projects. Being able to set apart time to just work solely on my own projects was really enjoyable and gave me a taste of what being able to work solely on my own projects would feel like and it was great!

Along with building these projects, I wanted to power them using my own custom open source MVC framework called Mavoc. I haven't publicly launched Mavoc, but I'm really happy with where the PHP version is at (you can see it used in all of my projects). It still needs some improvements, but it is a solid base that I plan to continue to use on all my projects going forward.

When I started this project, my follower account on Twitter was a total of 5 people. I've been able to bring that number up to 107 people. I realize that is probably really low numbers for most people but at the same time starting from scratch without using any networks to build that up is a good accomplishment, and I'm really happy with that number with the limited amount of time I spent posting online. The challenge gave me a way to authentically post about myself and network with other users without feeling awkward.

It also really gave me a good feel for what it takes to build a Twitter following from scratch. I created a theory that I call the "Divide By 5" rule. Basically if you do not have any viral tweets but you are regularly commenting and interacting with others, it will take roughly 5 posts to gain 1 new follower. If you divide a user's total posts by 5 (this tends to work for users with under 10,000 followers - it doesn't work as well on larger accounts), there is a good chance you are going to be around their follower count. This obviously does not apply if the user went viral or if they had a large following outside of Twitter. I currently have 873 posts so divide that by 5 and you get 175 rounded. I'm a little behind where I should be, but I could have commented on other people's posts more often.

By posting updates to Twitter, IndieHackers, HackerNews, and this blog, it forced me to publish and interact with others more and also gave me a blueprint of how I want to proceed going forward.

Bad

Although there was a lot of good there was also some bad that came along with the challenge. I definitely failed in reaching my goal of launching 12 startups. I also did not reach anywhere near as many people as I was hoping to reach. When I launched MetricRiv (originally called NumbersQ), that launch post made it to the front page of IndieHackers in the featured section which brought in a lot less traffic than I was expecting. Every other place I posted about my startup, there was 0 response. When I posted my first two projects on HackerNews, they did not receive a single upvote. When I would try to promote my projects on social media, it would feel like yelling into the void with no one interested.

I knew the market was saturated with people launching projects but I was hoping that my projects being open source would help move the needle a little bit but it seemed like it had very little affect on the interest level in my projects (I think it did help with networking on Twitter because it was a unique talking point that people would ask about).

The second project I launched was the Twitter client TwitRiv. Focusing on TwitRiv for my second project was probably a mistake but I don't regret it. When I started the challenge, I wasn't originally planning to build a Twitter client (it was planned, just planned for later). However, I was starting to see some growth in my Twitter following and Twitter was running a Hackathon with cash prizes. The Hackathon due date was going to come before I originally planned to focus on building TwitRiv so I decided to reshuffle my projects and focus on TwitRiv next.

Unfortunately, that plan turned into a mess. Before starting I had assumed that the Twitter API would be a solid, simple base to build on but it was actually very frustrating to work with and there were unaddressed bugs. For example, TwitRiv was supposed to show users their timeline, however when you called the API timeline endpoint it wouldn't always include the pagination details. Meaning it would retrieve the latest list of posts but there was no way to retrieve more posts. This pagination bug was sporadic, sometimes everything would work perfectly and other times it wouldn't.

The more I got into it, I also realized that the free tier of the API that I was using was going to have major limitations on the way I wanted to use it. For example, you could only have a certain number of requests across your app. If my app was successful and was able to onboard a lot of people, I would very quickly run out of API requests. I had to build in some additional restrictions to make sure individual accounts wouldn't run through the API credits. None of this is completely out of the norm for API limitations, but I was used to browsing Twitter on the free and open Nitter alternative that used the internal Twitter API with no limitations so trying to work through the official public API endpoint limitations was another frustration.

I was able to launch in time for the hackathon but I didn't win any prizes. And very shortly after that Elon Musk purchased Twitter in October 2022. I spent a lot more time than I should have working through the Twitter API limitations and then not too long after that, timeline based apps started getting rejected from using the Twitter API (it was determined that apps could not mimic Twitter behavior) and then the free Twitter API was shutdown making TwitRiv completely unusable. The site is still up but it doesn't work. I'm not sure what my plan is going forward.

The work on TwitRiv is not all lost. It helped me learn quite a bit about some of the complexities of social networks and it also helped me move my Mavoc framework forward. Unfortunately, building the Mavoc framework was another item I need to also list under the bad.

My original plan was to build my 12 projects in PHP, Node, and Go. I'd built projects in PHP and Node before, but I hadn't built anything significant using Go (I was wanting to build a really simple project using Go). As I was working on adopting my Mavoc framework for Node and Go, I ran into a number of issues that really slowed me down. I ended up spending time working through framework issues instead of working through startup issues. Spending time trying to get your own custom framework working is frustrating when you are on a time crunch to get projects built. I ended up having to put the Node and Go projects on hold and just focus on PHP projects.

I think the PHP version of the Mavoc framework is in a good place but the Node and Go versions are going to have to wait until I have more time that I can dedicate to getting them off the ground. I don't regret building a custom framework but it did end up taking a lot more time than I had anticipated.

Along with delays in building the framework and focusing too much on the TwitRiv project, the other items that really pushed everything behind schedule was client work and a couple real estate transactions. As a freelancer, I had cleared enough time and funds in my schedule to be able to work full time on the challenge from July until roughly October or November. I was hoping that I would see some traction in one of my projects that would extend my runway. Unfortunately, that was not the case and I had to start spending a lot of time focusing on client work, especially at the beginning of 2023. The client work left little time for me to focus on my own projects.

Then in the spring of 2023, there was the opportunity to do a couple real estate transactions. The real estate transactions ended up requiring a lot of my time to work through the details because there was a time-sensitive component involved. Thankfully they were successful, but it also left very little time to work on the challenge.

As the time counted down, I was really optimistic that I would be able to churn out some projects but ultimately that wasn't the case. The third project I took on was FeedRiv which is an RSS reader. I'd worked with RSS before in some of my own personal projects that weren't public, but during development I realized building a public RSS reader is a lot different than building a private reader. I had to work through a number of issues to handle edge cases to make sure the project was user friendly, and it still has a bit of work to really get to where I would like it to be.

Another issue that was a bit more frustrating than I anticipated was that putting out everything as open source definitely took more work than I had planned. I needed to add documentation for each project to explain how it works and how to set it up. Doing all that while making sure you are not revealing any sensitive, private information takes more time. I don't regret doing everything open source and I plan to continue releasing items as open source going forward, but I'm not sure if there was any significant benefit to it.

The final issue that I need to discuss is the schedule I laid out in my original launch post. In that post I committed to posting 12 times and I said if nothing else, each month I will simply post "I've failed." Well, I failed to live up to that commitment. After I got started, I realized filling my blog with one sentence posts was not something I wanted to do. I tried to add notices to the top of the blog to give an update on where things stood but I definitely should not have committed to the schedule I outlined.

Recommendations

For anyone considering taking on the 12 startups in 12 months challenge, I would highly recommend it. My assumption is that if it is even something you would seriously consider, it probably is a challenge that would benefit you.

I did not have a successful conclusion but it pushed me forward in areas I really wanted to grow. I was starting from a place where I was good at building, had no social following, had a lot of ideas of what I wanted to build, but I wasn't sure which idea I wanted to focus on. I also had a bit of time and funds available (at least a few months) to get a running head start with the challenge. If you are finding yourself in a similar place, then I definitely encourage you to give it a try.

I would caution against having big expectations that when you complete everything you will have a successful business or thinking it will solve all your problems, but if you go in with the goal of simply growing in areas and using it to help you focus, I think it will be worth it. That being said, don't be afraid to dream big, you may end up having amazing results, you never know if you don't try!

I think the biggest benefit of the challenge is that it forces you into action and action is one of the best ways to grow and learn.

What I Learned

Through it all, I learned a lot. I think one of the biggest things I learned was how much work it takes to market a project from scratch. The market is very saturated with startups and projects that people are trying to promote, and it makes it very difficult to break through the noise if you haven't already built a network (and from what I've seen, sometimes it is still hard even when you have built up a network).

Some developers seem to really gravitate towards switching back and forth between a coding week and then a marketing week. I've seen this concept really promoted by Jon Yong of Two Bear Software. I may try that at some point, but it never has matched up well with the way I like to handle my schedule. I tend to like focusing on something to completion and stopping after a week would feel like I was leaving things unaccomplished.

Going forward, I know I need to spend a lot more time and energy on sales and marketing and less time on building. Like many developers, building is where I feel comfortable. Working to promote my work always has felt weird to me - I tend to approach things as "I built this, if it is good and you are interested, great, but if not, no problem." A kind of take-it-or-leave-it approach to marketing and sales will lead to failure if you are a solo founder like myself.

From what I'm seeing, there are not many resources for learning how to effectively handle marketing and sales from the perspective of a developer. Most times when successful founders are interviewed, they kind of gloss over the initial marketing and sales. They'll say something like "I reached out to 100 people and from there everything really started taking off" but that "reached out to 100 people" brings up a lot of questions (at least it does for me): How did you find these people? What type of communication (email, phone, direct messages, etc.) did you use? Were you concerned about spam laws or app restrictions? What was your percentage of responses? What did you say? Did you know any of these people previously or was this all cold outreach? What specifically did you say in your messages? And many more questions.

I think there is a major gap in the market on how to move developers from the process of building to the process of selling. And all that leads us to next steps.

Next Steps

Now that the 12 in 12 challenge is over, I've been debating what specifically I want to focus on moving forward. There are a few apps that I've wanted to create that I didn't get a chance to build but at the same time, my ultimate goal is to have my apps be able to fully fund my salary. I'm currently still doing freelance work and not anywhere close to being able to work on my own apps fulltime.

I've realized that if I go build the apps that I want to build, I'm just going to wind up in the same place with a need to market and sell. I already have a working product in MetricRiv that I'm proud of. Going forward, my plan is to start investing more time into marketing and sales for MetricRiv. As I've started thinking about this transition, I started realizing that there are very limited resources to help developers with selling.

There are a lot of resources to help developers "build in public" but there are not a lot of resources to help "sell in public." As I start down this journey of sales and marketing, I want to start putting together selling resources specifically geared towards solo developers, makers, and creators.

A lot of the sales advice seems to be focused on people whose fulltime job is sales or the other advice tends to be focused on helping established businesses improve their sales pipelines. There are very few resources to teach small independent creators how to sell their projects. Right now, the #BuildInPublic hashtag is well known. I would like to see the #SellInPublic become just as popular. I've been able to purchase the sellinpublic.com domain and I'm excited to start documenting helpful resources for small developers looking to learn about sales and marketing.

Startup #3 has officially launched! FeedRiv.com is a simple RSS feed reader that lets you tag and rate items. I use FeedRiv to track freelance developer opportunities. The open source code is available on Github: DashboardQ FeedRiv.

1. Overview
2. Inspiration
3. Drawbacks
4. Schedule
5. Next Steps

Overview

The goal of FeedRiv is to provide the tools needed to quickly filter RSS feeds and pull out the most important information. FeedRiv allows users to rate individual feed items. Those ratings are then used to provide an "auto rating" to future items. The list of items can be sorted so that the items with the highest auto rating appear first in the list.

Along with ratings, the system also provides a custom tagging and filtering system. Users can create tags and then apply them to individual items. There are filter links so that users can then filter the displayed items that have been tagged. For example, you could tag items where you want to respond with "To Respond" and then when you have time to respond, you can filter the list to only show items with the "To Respond" tag.

Inspiration

Blogs and RSS feeds were very popular between 2005-2013 when the Google Reader app was launched and free to use. During this time I would often use Google Reader to track freelance contractor jobs from Craigslist. I would subscribe to all the major metro areas and look for jobs that matched my skillset. Eventually Craigslist fell out of favor for posting freelance job opportunities and Google Reader was shut down in 2013.

The freelance marketplace Upwork still provides an RSS feed of the jobs in the marketplace. One of the really nice things about the RSS feed is that you can filter it so that it will only show jobs that match a certain criteria. Even though you can filter it, there is often still a lot of jobs that come through that don't match what I'm looking for. A while back I created a simple bare bones app made just for me that would further filter the Upwork RSS feed.

When I start the 12 startups in 12 months challenge, I knew that creating an RSS feed reader that matched the functionality I needed would be one of the startups I would launch. Although RSS has lost a lot of popularity over the years, it still has a fan base and is still regularly used.

Drawbacks

FeedRiv is mainly designed for my own needs. It has a number of limitations that could be improved. Some of the basic drawbacks are that the interactions are not fully integrated. For example, when you archive an item, the item is removed from the page but the item counts don't change until you reload the page. This could be improved with additional coding but I had already spent more time thant I had anticipated on this project and it was meeting my basic needs. I'm not expecting a lot of people to use this project so spending a lot of time on features that didn't bother me too much did not seem like a wise use of time.

One of the biggest ways RSS feeds are still used is with podcasts. Podcasts use RSS to broadcast episodes. I don't have any plans to use FeedRiv as a podcast player so at this time, it does not have the functionality to display/play podcast episodes.

Schedule

The launch of this project is well outside of the 12 months for the 12 startups in 12 months project. I was about halfway through with this project when the 12 months were up. Even though the 12 months were complete, I wanted to finish the project I was working on.

One of my next goals is to write a wrap-up post summarizing my experience doing the 12 in 12 challenge. Even though I wasn't successful, I would highly recommend it to anyone with a lot of ideas who can't figure out which project they want to focus on.

Next Steps

Along with the wrap-up post I mentioned, my future plans are to focus on marketing MetricRiv and instead of building more apps, I'm considering reaching out to potential customers before building anything to get customer feedback from the very beginning. Sales and marketing are my weakest skills and I really want to work on improving those skills going forward.

Startup #2 has officially launched! TwitRiv.com helps gives users the tools they need to better control their Twitter experience. My approach to Twitter is to promote others, share helpful content, and connect with others. TwitRiv was built as tool to help me accomplish these goals.

1. Overview
2. Inspiration
3. Drawbacks
4. Schedule
5. Next Steps

Overview

The goal of TwitRiv is to provide the tools needed to work efficiently on Twitter on both desktop and mobile devices. The main Twitter timelines make it difficult to see posts from specific users. I often prefer pulling up individual user timelines and reading Twitter that way. Reading user timelines is not easy on Twitter and you have to remember the accounts that you want to check. TwitRiv has a "cycle" system that shows you recently visited timelines.

It also provides tools that allow you to add notes to a tweet and mark the tweet as a todo so that you can come back to a todo list to respond and interact in some other way with the content.

Inspiration

A major inspiration for the project is the Nitter.net site. It is a quick loading site that allows you to load Twitter content in a fraction of the time it takes to load on Twitter. Unfortunately, Nitter does not have a way to login and interact with the content from your own Twitter account. The idea for TwitRiv was to create a site that loads similarly to Nitter but shows the content tied to your specific Twitter account.

Along with quickly loading only the content you want to see, TwitRiv adds specific tools that allows users to interact on Twitter in a more efficient manner without all the additional distractions that Twitter displays.

Drawbacks

While working on this project, I ran into a number of drawbacks. The Twitter API has some inconsistencies which then caused additional debugging time (for example, it is supposed to provide ways to page through data but for the main timeline, if you do not include replies, then it won't always provide additional pages of information).

The Twitter API also limits what information is available. For example, in some circumstances, it will not show content that is older than 7 days. This limits some of the original goals of the project - because Nitter is not using the official API, it is able to work around some of these items but with TwitRiv using the official V2 API, there are limitations that cannot be worked around.

Twitter also has limits on the total amount of content that can be pulled each month by the application. Due to these limitations, only 10 premium accounts will be available at launch. Premium accounts receive access to Twitter-limited features. The premium limit is to help ensure that I don't lose access to Twitter API resources for the premium accounts. Once some caching features are added and I have a better feel for the resource usage, I'm hoping to expand the amount of premium accounts available.

Schedule

The launch for this project is significantly behind schedule. The 2nd startup was originally supposed to be launched August 31st. There are a number of reasons for the delay. Twitter had a hackathon where this project was entered at the end of August so the initial code was working but my goal is to build projects that I actually use. At that point, TwitRiv was not in a state where I would want to regularly use it.

I was also running into Twitter API limitations mentioned above in the Drawbacks section. I ended up spending a lot more time than expected trying to figure out solutions to the Twitter API limitations. The Twitter API limitations made things difficult to get it to a state where I would want to regularly use it.

Some freelance client work also came up and it ended up taking a significant amount of my time I was planning to devote to these projects which also pushed things farther behind schedule. All that to say, there have been a number of issues that have pushed things back.

Next Steps

My plan moving forward is to focus on getting everything back on schedule. Startup 3 has a launch goal of Wednesday, November 30th and I'm hoping to launch two more projects after that by the end of the year. I'm not sure how successufl I'll be in reaching these goals, but if I am successul, it would put me at 5 startups launched in 6 months which I would be really happy with.

Right now Startup 3 will be an RSS feed reader with a unique feature that I haven't seen anywhere else. As I'm working on Startup 3, I may end up shuffling projects around but right now that is the plan.

Thanks for all the support - see you soon!

Startup #1 has officially launched! MetricRiv.com helps users track business and marketing numbers to stay up-to-date on the state of their business.

1. Overview
2. Inspiration
3. Schedule
4. Next Steps

Overview

The goal is that the MetricRiv will be the first page business owners check when they get started in the morning. The website is set up so that users can connect with other online services and pull in those numbers. Instead of trying to provide a lot of explanations, I figured it would probably be easiest to show a working example. You can see my live MetricRiv page here:
https://www.metricriv.com/agraddy

As you can see, it provides live numbers on revenue and social media marketing. The numbers can be customized for each user. Anyone who is sharing numbers publically can use it for free. In order to have a list of private numbers that cannot be viewed by others, there is a monthly fee.

Inspiration

While working with one of my previous startups, I was trying to run a marketing campaign and all I wanted to know was the daily advertising costs. It was always frustrating how much time it took to load up the dashboard to just learn one number. I knew that I could pull that number out with the API.

What I've normally done in the past is build a custom tool that solves my own problem and then move on. But this time I decided I should try something different. Instead of building the tool just for me, I would build the tool so that I could sell it to others too. I ended up creating the initial marketing page a couple years ago but then never actually built the service.

When I was starting this 12 Startups in 12 Months journey, I knew that MetricRiv was the first startup I wanted to build.

Schedule

The launch day for this project is about 2 and half weeks late. I knew this first launch would involve a lot because I would be building a lot of the foundations for the future projects. It would have been nice to launch on time, but I'm really happy with where everything is at. Here is the upcoming schedule:

• In about a week to a week and a half, I'll be releasing the open source code on Github and doing a Show HackerNews post.
• In about a week and a half, I plan to do a Product Hunt launch.
• Then, two and a half weeks from now, Startup #2 will be launching.

I'm now playing catch-up on everything so these are aspirational goals that I may not meet.

Next Steps

The next startup launches Wednesday, August 31, 2022. Originally I was planning a different startup for number two, but I found out about a Twitter hackathon with a due date of August 19th. I was planning a Twitter tool for one of my later startups but I'm moving it up to number 2 so that I can try to get it submitted to the hackathon (a competition to build new apps).

My philosophy on using Twitter (and any other social network) is Promote others, Share what your learn, and Connect users with each other. I haven't found a Twitter tool that really matches my philosophy (although there are a few that comes close to what I'm wanting). Most of the Twitter tools I see help you create content; I'm looking for a tool that lets me help others. There is a very short window for the initial due date so the features on the initial launch will be fairly limited.

Thanks for all the support, I'm grateful to be on this journey. See you soon!

Startup #1 has officially launched! NumbersQ.com helps users track business and marketing numbers to stay up-to-date on the state of their business.

1. Overview
2. Inspiration
3. Schedule
4. Next Steps

Overview

The goal is that the NumbersQ will be the first page business owners check when they get started in the morning. The website is set up so that users can connect with other online services and pull in those numbers. Instead of trying to provide a lot of explanations, I figured it would probably be easiest to show a working example. You can see my live NumbersQ page here:
https://www.numbersq.com/agraddy

As you can see, it provides live numbers on revenue and social media marketing. The numbers can be customized for each user. Anyone who is sharing numbers publically can use it for free. In order to have a list of private numbers that cannot be viewed by others, there is a monthly fee.

Inspiration

While working with one of my previous startups, I was trying to run a marketing campaign and all I wanted to know was the daily advertising costs. It was always frustrating how much time it took to load up the dashboard to just learn one number. I knew that I could pull that number out with the API.

What I've normally done in the past is build a custom tool that solves my own problem and then move on. But this time I decided I should try something different. Instead of building the tool just for me, I would build the tool so that I could sell it to others too. I ended up creating the initial marketing page a couple years ago but then never actually built the service.

When I was starting this 12 Startups in 12 Months journey, I knew that NumbersQ was the first startup I wanted to build.

Schedule

The launch day for this project is about 2 and half weeks late. I knew this first launch would involve a lot because I would be building a lot of the foundations for the future projects. It would have been nice to launch on time, but I'm really happy with where everything is at. Here is the upcoming schedule:

• In about a week to a week and a half, I'll be releasing the open source code on Github and doing a Show HackerNews post.
• In about a week and a half, I plan to do a Product Hunt launch.
• Then, two and a half weeks from now, Startup #2 will be launching.

I'm now playing catch-up on everything so these are aspirational goals that I may not meet.

Next Steps

The next startup launches Wednesday, August 31, 2022. Originally I was planning a different startup for number two, but I found out about a Twitter hackathon with a due date of August 19th. I was planning a Twitter tool for one of my later startups but I'm moving it up to number 2 so that I can try to get it submitted to the hackathon (a competition to build new apps).

My philosophy on using Twitter (and any other social network) is Promote others, Share what your learn, and Connect users with each other. I haven't found a Twitter tool that really matches my philosophy (although there are a few that comes close to what I'm wanting). Most of the Twitter tools I see help you create content; I'm looking for a tool that lets me help others. There is a very short window for the initial due date so the features on the initial launch will be fairly limited.

Thanks for all the support, I'm grateful to be on this journey. See you soon!

Modern web development has become selfish. We moved from an explosive period of growth where the focus was making websites and all of their technologies as open and accessible as possible to a new era where the focus is on developer satisfaction and productivity at the expense of end users.

1. Background
2. History
3. Complications
4. Current State
5. TACE
6. Final Thoughts
7. Addendum: Learning TACE
8. Addendum: Framework Compatibility

Background

It has become standard these days to assume front end web developers are using a framework. The original way to build a website using vanilla HTML, CSS, and JS are nowhere to be found. Framework surveys don't even acknowlege this method of development:

• State of JS Survey
• State of Frontend

If you develop using vanilla HTML, CSS, and JS it is hard to even answer "What is your front end stack?" type questions because even saying you use vanilla JS could mean anything (you could have built a completely custom JS library that generates all the HTML and CSS using no other code libraries and written it by hand in JS). When you answer "vanilla JS" that usually invites other questions like "How?" or "What do you mean?"

History

As a result of the framework emphasis, traditional forms of website development are ignored and many of the principles that formed those foundations are now missing in development conversations. Companies that have a vested interest in creating walled gardens and vendor lock-in are now driving many of the modern JavaScript and design libraries.

The principles that powered a really explosive era of growth in the internet (principles like "separation of concern", the "semantic web", "end user satisfaction", and "open standards") have been replaced with principles like "developer satisfaction", "streamlining collaboration", "managing intellectual capital", and "developer productivity" which have all the hallmarks of development being driven by large technology firms whose main goal is to drive down developer costs and increase output.

As a sidenote, I don't necessarily have a positive or negative issue with those goals, but I do not think they are the proper goals for a healthy, successful, collaborative web community that was being built in the 2000-2010 decade.

Complications

The focus has shifted from the open web and making everything accessible and customizable for the end user to focusing on the developers and making sure the developers can quickly output projects at the expense of the end users.

It has created longer load times due to bloated code, difficult to access interfaces (most of the content isn't loaded until after the JavaScript is loaded which means to parse the contents you can no longer use a simple command line download program, you now must use a browser or simulate a browser with JavaScript functionality), less customizability from the end user, and from my experience, higher chances of a browser crashing or slowing down.

A good example is to compare Twitter (a site developed with modern front end techniques) with Nitter (a site developed with traditional front end techniques) (Nitter is an open source alternative interface for Twitter - it is free and open source and may be down from time-to-time due to Twitter API restrictions or simply server overload on a free service). Try opening these two links using incognito browser windows on your phone (incognito so that you are not logged in):

• https://twitter.com/indiehackers
• https://nitter.net/indiehackers

When this free service is stable, Nitter loads much faster for me (if that Nitter link is not loading properly, you can use this alternative link: https://nitter.it/indiehackers). Now try scrolling as far back as you can on the Twitter link - eventually my browser slows down and/or crashes (note at the time of publishing, it looks like Twitter now puts up a banner to sign up if you scroll too far). If you do the same on Nitter, you can navigate from page to page until there are no longer any posts.

Another test you can run is to use your browser's View Page Source option when you right click and compare the easy to read Nitter output versus Twitter's output. The output of Twitter is a modern mess of complicated scripts while the Nitter output is clean, easy to understand HTML.

I'm not picking on Twitter, they are just one example where it is easy to compare with the alternative. If you want another example, try Reddit and compare it with the free alternative Teddit:

• https://www.reddit.com/r/indiehackers/
• https://teddit.net/r/indiehackers

Why are all these popular websites having alternative interfaces created for them? When these sites first came out, alternative interfaces were being created off the free and open API interfaces which offered unique takes on interacting with the sites. These days, companies no longer value the open web or their end users and alternative interfaces are now created to try to escape the increased control of these platforms.

Current State

If you look at the reasons why most companies switch to a modern web stack, it is because their developers wanted to try out the latest technology, or because they wanted to be able to onboard developers as quickly as possible, not because the latest technology actually helps their end users.

Web developers used to be proud of how neat and clean their HTML was displayed when a user viewed the source. Some companies would advertise job openings where only people who viewed their source code would see the job opening. Easy to access source code made it easy for people to learn new techniques and to just learn web development in general. Now when users view the source, they see a link to a JavaScript file that will later load the HTML.

Despite this "developer focus", many developers are frustrated with the constant churn of modern JavaScript front end libraries - most of the reasons for the churn are due to trying to solve problems created by these very same frameworks. Concepts like SSR (server side rendering), HMR (Hot Module Replacement - needed because reloading a web page takes a long time with modern frameworks), Tree Shaking (getting rid of all the bloated code that is not needed), and Lazy Loading (only loading code as needed because it takes too long to load all the code at once). Most of these solutions are really ingenious but they wouldn't be needed if traditional web development was used.

To sum it up, modern web development has become selfish. The only way to resolve this issue is to change the focus from "developer productivity" back to "end user satisfaction."

TACE

If you don't have a name for something, it doesn't exist.

With that in mind, I would like to introduce you to the TACE Front End Framework (rhymes with "ace", pronounced /tās/). The word "tace" is an obscure alternative word for "tasset" which is a type of armor. When you use the TACE framework, you are building sites that are protected from obsoletion (when built properly, they are easily maintainable and updateable in the future) and you are also protected from the constant churn in the industry.

The TACE Framework has four basic principles:

• Triad - Front end web development should consist of three separate parts, also known as "Separation of Concerns." Any website that adheres to TACE will separate the HTML, CSS, and JS into separate files with minimal exceptions and the following standards will apply: The JS will not generate the CSS and HTML. The HTML will not contain CSS or JS. The CSS will be maintained separately from the HTML and JS.
• Accessible - The HTML content should be easily accessible by both humans using the browser "View Source" functionality and machines parsing the page should be able to load the URL with basic tools like wget and curl. The content should be "Semantically Structured" for easy parsing.
• Client - The end user and device that is accessing the site should be prioritized over developer productivity - this includes loading time and browser memory usage. When TACE is used, the site is being developed with the client in mind.
• Expose - Combining the three principles above, clients should be able to easily access the HTML, CSS, and JS of the site in a non-minified, easy to read format. All of the code should be exposed and easy to view by the end user which encourages learning and sharing.

If you follow the above principles, then you are using the TACE framework. Now when asked what framework do you use, instead of saying "I use vanilla JS", you can just say "TACE" to answer the question.

Final Thoughts

There appears to be a shift currently happening again in web development. Statically generated websites are becoming much more popular (it is almost like a violent reaction in the opposite direction of bloated single page apps). Most of these statically generated sites are still using a lot of the modern build tools that I believe cause a lot of developer frustrations (especially for people who are new to web development and trying to figure things out). I would like to see more people move to hand written HTML, CSS, and JS but I think statically generated websites (even if they are built using complicated tooling) is a good direction for the web development community.

For anyone looking to get into web development, I would highly recommend taking a look at writing your HTML, CSS, and JS by hand. It may initially sound awful, but if you are using a solid text/code editor, it will become very enjoyable and give you confidence that you have complete control of your site (you won't have to spend time figuring out why your build tool is throwing an error). Following the TACE Front End Framework principles will help you understand the basics of what is happening when the browser loads your code.

If you have no idea where to start. Start with HTML. Write HTML to match your content and only your content. Once you are happy with your HTML, then write CSS to add styling to your content. Every now and then you may need to make a minor adjustment to your HTML (add a class or move some tags around) but overall you should be able to fully style the page without having to adjust the HTML. Lastly, if you want to add interactivity to the page, then add JavaScript. All the hooks you need should already be there based off of the CSS you've written.

In my opinion, it is much easier to move up a level to modern frameworks when you understand the basics of HTML, CSS, and JS rather than starting with a modern framework and then trying to move down to lower levels of code. What I have found over the years of development is that you learn a lot more and your confidence grows when you understand lower level functionality. But be careful, once you understand the lower level workings, you may not want to move up to higher level frameworks.

So next time you are asked, "What front end framework are you using?" be sure to answer "I'm using TACE."

Addendum: Learning TACE

So if you are just starting out, how do you learn TACE? First, don't get too caught up on trying to learn techniques. Figure out what you want to accomplish, then learn the techniques needed to accomplish what you want.

If you are completely brand new, generally there are at least three file types used, each with a specific purpose. The only one you have to have is HTML:

• HTML - Your site's content displayed in a structured manner.
• CSS - This adds styling (like color, text formatting, layout, and anything else that controls the "look" of the site)
• JS - This adds the interactivity (meaning if you click on a button, it shows a popup).

I recommend visiting sites that breakdown the basics of HTML, CSS, and JS. Here are a few sites I recommend:

General

• Mozilla Web Docs
  • Mozilla is the creator of the open source Firefox browser and provides great documentation on web technologies.
• Savvas Stephanides - Dev, Explained
  • Some really simple break downs of web development technology. You'll probably want to start towards the bottom of the page.

HTML

• Khan Academy - Intro to HTML/CSS
  • I have not watched the full series but what I sampled looked great.
• HTML.com
  • Provides a really great introduction to writing HTML.
• Simplilearn HTML Introduction
  • A great, quick overview of HTML and how it works.

CSS

• CSS-TRICKS
  • The main site keeps you updated on the latest CSS techniques but there are breakdowns of just about every CSS option you can think of. They are my go-to resource when I need a refresher on something:
    • Flex Box
    • CSS Grid
    • Tables
      • Tables can be surprisingly difficult to style at times, especially for someone new to web development.
  • If you don't know/understand these terms, don't feel overwhelmed. Only learn them, when you need them.
• Defensive CSS
  • This is a website that provides examples on how to accomplish specific techniques using CSS.
• CSS Games:
  • CSS Diner
    • This helps you learn how to use CSS Selectors (the very basic building blocks of CSS).
    • The text on the right side of the screen and the "Help, I'm stuck!" popups are both helpful to read.
    • The first answer (at the time of writing) is "plate" then press <ENTER>.
  • Flexbox Froggy
    • This game helps you learn flexbox which is used for spacing items in CSS.
    • I think it does a great job explaining what it is trying to teach you.
    • The first answer (at the time of writing) is "justify-content: flex-end;" then press "Next."
  • Flexbox Defense
    • This game helps you learn flexbox which is used for spacing items in CSS. If you don't understand what flexbox is, make sure you understand the basics at the CSS-TRICKS link above.
    • The text on the game can be a bit overwhelming but the animations are a lot of fun! The drop downs with the right arrows in the intro text provide details on how to use a property.
    • The first answer (at the time of writing) is "justify-content: center;" then press "Start Wave."
  • Grid Garden
    • This game helps you learn CSS grids. Grids are a fairly new technique but very powerful way to layout a website page.
    • Like Flexbox Froggy, the text does a great job explaining what you are learning.
    • The first answer (at the time of writing) is "grid-column-start: 3;" then press "Next."

JavaScript (also abbreviated as JS)

JavaScript is an actual programming language used for many purposes outside of web development so the learning can be a bit more complicated and confusing. The good news is that you can build some great websites using just HTML and CSS and then you can sprinkle in Javscript when you need it.

Another thing that makes JavaScript difficult to learn is that is has evolved over the years. The old style code still works, but there are now new ways to write code that works in modern browsers. If you come across JavaScript code that has "var" in it, then it is probably classical style JavaScript and if the code has "let" or "const" in it, then it is more modern style JavaScript. Either style works (I personally prefer writing in classical style JavaScript, but if you are learning, you should probably learn modern style JavaScript since that is what everybody is using these days - also, no one refers to them as "classical style" and "modern style" - those are just my own terms).

• Khan Academy - Intro to HTML/JS

• JS Games:

  • JavaScript games are a bit more complicated than the CSS games.
  • JSRobot
    • It looks like a great way to learn the basics of JavaScript.
  • Elevator Saga
    • An interesting little game. Not sure how well it actually teaches JavaScript.
    • The first answer (at the time of writing) is to add "elevator.goToFloor(2);" to the code and then press "Apply"
    • You can speed up the time at the top right where it says "2x" - just increase that.
  • CrunchZilla
    • It looks like it teachs working with JS to output graphics. Depending what type of site you are building, you may not use this type of JavaScript much.
  • Untrusted
    • It gets really complicated really quick and the style of JavaScript is a little different than what you would be doing in normal web development.

Miscellaneous

• Various other helpful links.
  • CanIUse
    • Browsers are always adding new features. If you need to see what browsers support a feature you want to use, this is a great place to check. Here is their CSS Grid page:
      • CanIUse CSS Grid
        • I would focus on using features that are supported in the latest versions of Chrome, Firefox, Safari, and Edge if you are just starting out.
  • Hex Invaders
    • Colors in CSS are usually in a color code format called "Hexadecimal Colors" - this game helps you get used to how the color codes match up to actual colors.
  • Pixact.ly
    • Items are often sized and positioned in pixels. If you are not used to them, this game can give you an idea of their size when positioning elements.
    • I would note that I'm terrible at this game and have been working with pixels for over 20 years.
  • Simplilearn HTML Game Structure
    • It may overpromise a bit - you don't end up with an actual game at the end but I really like how they explain everything and lay everything out.
    • The nice thing is that it uses TACE.
  • View the source of this blog. The code is not formatted nice and neat but you can see how a really simple website is structured.
    • If you are not sure how to view the source code, try right-clicking in a blank area of this page and see if there is a "View page source" option or something like that.
    • When you view the source, you will see links to the CSS files at the top and links to the JS files at the bottom. If you click those while viewing the source, you will then be able to view the CSS or JS files.
    • You can also view the source by opening your browser developer tools.
      • Balsamiq has a great tutorial on how to open developer tools: Finding Your Browser's Developer Console
        • Note that the Firefox example shows how to open the console - you want to open the "Web Developer Tools."
      • The "Elements" tab will show the HTML and associated CSS nicely structured (and you can even edit and change it to see what happens).
• Miscellaneous Games

Addendum: Framework Compatibility

I would encourage you to write your HTML, CSS, and JS directly as much as possible and keep things as simple as possible. That being said, there are frameworks that can help.

Each of my projects for the 12 Startups in 12 Months (Open Source Edition) challenge will be using TACE.

That being said, below is a categorization of various libraries and frameworks. If you know of a modern framework that you believe is TACE compatible, please let me know so I can add it to the list. Also note, that I may have miscategorized projects below. Some of them I know better than others, but I may not be familiar with the latest version as things are constantly changing.

Note, just because a framework listed below is not TACE does not mean I don't think you should use it or that I think it is a bad project. I'm simply trying to define what falls within the TACE framework and what does not.

So what are some practical examples of this.

TACE Compatible

• HTMX would be a modern example of a library that adheres to TACE. The HTML has some hooks added to it but that does not affect any of the four principles.
• Alpine.js has similarities to HTMX. Due to the limited properties that can be invoked, I would consider Alpine.js to be within TACE framework principles.
• Hibiki HTML has a unique system for front end development. It uses custom HTML elements but the output meets the four principles of TACE.
• Knockout integrates well with traditional styles of development and matches the four principles to be TACE compatible.
• jQuery - yes it is old, laughed at, and despised, but it falls within TACE. Don't be embarrassed or ashamed to use jQuery.
  
  I see new, very talented developers feel shame for using jQuery when they are turning out projects that other, more experienced developers only dream of creating using modern frameworks (just to be clear, there are new, very talented developers who are turning out projects others only dream of in modern frameworks too, I just want those using jQuery to not be ashamed of their work when asked "What's your tech stack?").
  
  Mike Munroe from OBLSK mentioned on Twitter that jQuery has some security issues. It is a good point that I should emphasize. Here is a good, although a bit technical (if you are new to JS), overview of the issues that you can run into with jQuery: PSA: jQuery is bad for the security of your project.
  
  Make sure you are using secure practices when sending/loading AJAX calls, working with third parties, and outputting/generating HTML. Note that these concerns also exist when using vanilla JS.
• Bootstrap - yes, it is TACE compatible. I have mixed feelings overall about Bootstrap. I think it spurred on a major open source design movement, but it is also one of the major culprits of how we ended up where we are today in modern front end development.
  
  Bootstrap taught a generation of developers that to write HTML you need to think about CSS (which I'm guessing has led to lots of developers hating to write HTML based on comments I've seen). When writing HTML, my recommendation is to focus on writing HTML that matches the content. If you only think about what tag matches which content, it becomes a very enjoyable experience. If you are having to match your HTML to a CSS framework's requirements, it is going to be a very frustrating experience.

Borderline TACE Compatible

• Vue.js can be used in a TACE compatible way, but it can also be used in an incompatible way. To my knowledge, the JavaScript is generating the HTML in some circumstances which would break the Triad principle so I consider Vue.js to be borderline depending how it is used.
• Hyperscript is the companion to HTMX. Due to it using an interactive scripting language directly in the HTML, it does not fit in well with TACE. Because it is an open ended language, it is borderline out in regards to TACE compatibility since it does not maintain a separation of concerns.
• Tailwind - It separates the CSS out to a separate file but then it has the developer write all the CSS as classes in the HTML. Classes should be used as hooks in the TACE system - with minimal exceptions, classes should not be the styling themselves.

Not TACE Compatible (most of these do not fulfill the Triad principle due to the JS generating HTML)

• React
• Angular
• Svelte
• Next.js

TACE Compatible Backend Frameworks (these play well with TACE and would be considered compatible or borderline compatible with TACE):

• Phoenix LiveView
• Laravel Livewire
• Ruby On Rails Hotwired
• Django Unicorn

My recommendation is to always write by hand if you can because you have much more direct control of the end result, but if you feel you need to use a framework, hopefully the above list will clarify where the frameworks stand in regards to TACE compatibility.

My goal for the next 12 months is to launch 12 startups and release the source code for each startup under an MIT open source license.

1. Background
2. History
3. Philosophy
4. Open Source
5. Schedule
6. Final Notes
7. Progress Report

Background

I've been a full-time freelance software developer for 15+ years with the ultimate goal of eventually transitioning to running my own bootstrapped startup. During that time, I've built numerous online apps and online store customizations for clients, but I've never launched a successful startup of my own. Most of my startups have failed due to poor marketing.

In 2020 and 2021, I rebuilt an SaaS service that I had built years before. One of my biggest weaknesses is marketing and I was determined that I was going to use the service as a tool to experiment and learn marketing and advertising. At the beginning of 2022, my goal was to spend a little bit of my free time each day optimizing the advertising for the site. I absolutely dreaded working on the advertising and just about every part of my body seemed to despise working on it. I started realizing this was not going to work. The SaaS never crossed $100 / MRR (for those not familiar with MRR, it never averaged more than $100 per month in revenue) and I decided that it was time to focus on a different approach.

I had a few other ideas for services that I wanted to create and started reexamining the best approach for potentially marketing these services. In the process of research, I came across Plausible.io and their story of creating an open source analytics product. I've always been a big proponent of open source software and their story really resonated with me and seemed to line up with one of the ideas I had (taking on a market incumbent that offered a "good-enough" service for free).

However, I had other ideas I wanted to do as well. As I was investigating ideas in the IndieHacker community, I came across various posts about 12 Startups in 12 Months and it all seemed to make sense. I decided to combine the concepts of 12 Startups in 12 Months with the open source concepts that Plausible was implementing and have created the: 12 Startups in 12 Months (Open Source Edition).

History

Many people over the years have taken on the "12 Startups in 12 Months" challenge. For those of you not familiar with the challenge, it started in 2014 when Pieter Levels announced the goal to launch 12 startups in 12 months. I remember hearing about Pieter's goal at the time and thinking "that sounds like a crazy idea but is a really impressive goal." Pieter ended up launching 7 startups before deciding to focus on the startups that were really taking off.

After Pieter, there have been other people who have taken inspiration and started their own 12 startups in 12 months. Most have not completed the challenge but many of them have successfully launched new ventures out of the challenge. Here are just a few examples of others who have taken on the challenge:

• 2018: Jon Yongfook: 12 Startups in 12 Months - launched 7 startups and then successfully pivoted to BannerBear.
• 2020: Monica Lent: Let's go! The 12 Startups in 12 Months Challenge Starts Now - combined with 5 others to do the challenge together and the results can be seen on the 12x Startup site.
• 2021: Sam Shore: 12 Startups in 12 Month - only seemed to launch one startup and is now focusing on that fulltime: Typeshare.

There have been others who have done different variations of the 12 in 12 challenge. IndieHackers has a 12 Startups in 12 Months Group. Overall, most people who have taken on the challenge have experienced various levels of success.

Philosophy

Different people have different reasons for taking on the challenge from wanting to focus on finishing things, to working on launching, to increasing probability of success, to quickly working through ideas. My thoughts are similar, I have a tendency to have a lot of ideas but I often enjoy the planning and building but the actual launching and marketing aren't as enjoyable. By having a set schedule, it will force me to launch and market.

I generally prefer to listen and learn over share and promote, but I know that sharing and promoting is an important part of modern marketing. By launching 12 startups, it gives me a built in excuse for promoting because I'm simply giving updates on the challenge I'm working on. What would normally feel awkward to me, will feel more natural because I have a built in reason for sharing (it is part of the challenge).

With all the people taking on the challenge over the years, one concept I haven't seen mentioned is quantity vs quality. There is a really fascinating story from the Art & Fear book about a ceramics class where half the class focused on quantity and half focused on quality. At the end of the session, the group that focused on quantity ended up creating higher quality work than the group focused just on quality.

Jeff Atwood had a great blog post breaking this concept down: Quantity Always Trumps Quality. He mentions "Quantity always trumps quality. That's why the one bit of advice I always give aspiring bloggers is to pick a schedule and stick with it."

Another important concept, that I think ties into the 12 in 12 challenge, is Parkinson's Law which basically states that "work expands so as to fill the time available for its completion." By having a set schedule with aggressive goals, it focuses the work and increases output.

Some of the reasons why I believe the 12 Startups in 12 Months challenge has been successful for many of those taking it on is because it forces "Quantity over Quality" and also harnesses Parkinson's Law to increase productivity.

Open Source

Each startup that I launch will have the source code released under an MIT license. I'm approaching the open source portion of this project strictly as "open source" not "open contribution" similar to the SQLite approach: Open-Source, not Open-Contribution

One of the unique approaches I'm going to be taking with these startups is that they will have a unified login and billing system. Once you have created an account for one service, you will be able to login to any other service without creating an additional account. The startups will have a unified billing system so that you will receive a single monthly charge for all the services you subscribe to.

This unified login and billing system will not be open source. The open source version of each startup will include a login system, but it will not be the unified login system.

Schedule

I'm officially announcing the start of this challenge on Friday, July 1, 2022. The goal is to launch a startup on the last Wednesday of each month.

The plan is to also update revenue numbers each month for each project that has launched. My commitment is that you'll get 12 posts on the last Wednesday of each month. It may be a one sentence post of "I've failed" or it may be a "Here is the next launch" or it could be "I've pivoted." No matter what, I'll be posting at a minimum 12 times.

Here is the launch schedule for the next year:

• July 27, 2022 - Startup #1
• August 31, 2022 - Startup #2
• September 28, 2022 - Startup #3
• October 26, 2022 - Startup #4
• November 30, 2022 - Startup #5
• December 28, 2022 - Startup #6
• January 25, 2023 - Startup #7
• February 22, 2023 - Startup #8
• March 29, 2023 - Startup #9
• April 26, 2023 - Startup #10
• May 31, 2023 - Startup #11
• June 28, 2023 - Startup #12

Final Notes

Looking at others who have taken on the challenge, it seems like many of the people would come up with startup ideas from month to month. I already have a list of 12 different startup ideas (I actually have more than 12 and am having to decide which ones to focus on).

Many of these projects have arisen from other needs that I've had over the years or services that I have wanted where the solutions in the marketplace didn't really meet my goals. I've also learned that the more you build, the more you realize new services that you wish existed. My assumption is that building these startups will spur even more ideas.

I have a strong preference for simple and basic services that do what they say and do it well. There is a tendency among startups (especially those with venture funding) to continually add more and more features which in turn both raises the price of the service as well as the complexity. I believe there is strong demand in the marketplace for simple, affordable solutions.

I'm excited to get started - talk to you soon!

Progress Report

This section will be updated with links to the startups and should follow the schedule listed above.

Startup 1 - NumbersQ

Know your important numbers: Launch Post | Open Source Code

Startup 2 - TwitRiv

Take control of your Twitter experience: Launch Post | Open Source Code

Startup 3 - Current Launch Goal: End of February 2023

Trying to start something new can seem overwhelming. Maybe the task is complicated and complex. There are all sorts of items you have to plan out and consider to avoid making the wrong decision. My recommendation is to start simple - pick a task that will move you closer to your goal and accomplish that task. When it is complete, move to the next task that needs to be completed. Slowly, step-by-step you will get closer to accomplishing your goal.

I needed to start this blog. As I was working through everything, I started trying to put together the perfect first post and realized I wasn't even taking my own advice. So I scrapped my original blog post (maybe I'll use some of the thoughts another time) and created this very short and simple post.

Having simple, attainable tasks that you can accomplish will give you a sense of progress and keep you motivated as you move closer to your goals.