In January, I found myself completely immersed in building an app centered around AI artwork generation. I dedicated about two weeks to this project, diving deep into everything related to Stable Diffusion. I experimented with running it on every laptop equipped with a GPU that I owned. The process involved creating an API for Stable Diffusion, generating images, and figuring out how to index and search them. I also explored existing open APIs that could facilitate this process.

To support this endeavor, I developed a new database service. I hadn't used Outfit.io before, but I discovered they offer some impressive PostgreSQL cloud options. It's quite neat! Additionally, I tried out Tinybird for the first time for ClickHouse. This was a game-changer for me because one of the major hurdles in using ClickHouse for personal projects, as opposed to work projects where I use it frequently, was the lack of an affordable and easy-to-use cloud hosting service for PostgreSQL. Tinybird seems to fill that gap nicely.

I built a Progressive Web App (PWA) and transformed it into a TestFlight Android app. The results were impressive, thanks to Capacitor. Although I don't regret the learning experience—it was genuinely enjoyable—I'm relieved to have moved past it. As exciting as it is to generate AI artwork and build apps, I realized I wouldn't want to start a company around this concept. The market feels very consumer-oriented and low-end, with unresolved copyright issues.

There's ongoing debate about whether Stable Diffusion itself is legally sound. The images used for training might fall under fair use, but courts could eventually rule that copyright is required for all training data. This uncertainty makes the output of these models questionable, and you might not be able to sublicense any of it legally.

While the applications of this technology are straightforward and easy to build, it's challenging to monetize them. There are countless apps available that allow users to generate images using Stable Diffusion on their phones. Despite their abundance, I don't find them particularly good. However, the sheer number makes it difficult to charge for such services.

Ultimately, I've decided to offer my app for free, covering minimal API usage costs myself. Currently, there's a limit of about 30 images per day per user. I'll see how sustainable this model is. If you're interested, you can check it out at pica.so—it's like Picasso, but with one 'S'.

Adobe recently announced its acquisition of Figma for a staggering $20 billion, split evenly between cash and stock. This deal doubles Figma's valuation and represents a 50x multiple on their reported $400 million in annual revenue. Many are questioning the logic behind such a high price tag, even considering the value of Figma's talented workforce.

As an Adobe employee, I have no insider information on the decision to acquire Figma. However, as a designer who doesn't use Adobe XD daily, I have some thoughts on the matter.

Adobe has long been a leader in native software, dominating various verticals since the 1990s. From raster graphics with Photoshop to photo editing in Lightroom, Adobe's suite has been a staple for designers. UX design traditionally happened in Illustrator and Photoshop, but these tools were never ideal for UX designers. After acquiring Macromedia, Adobe discontinued Fireworks, leaving designers to revert to Photoshop or Illustrator.

The design landscape has evolved significantly, with Figma emerging as a cross-platform, collaborative tool that fills a gap Adobe has struggled to address. Figma's dominance in this segment is undeniable, and Adobe's acquisition can be seen as a strategic move to capture this market.

Wall Street analysts largely agree that the $20 billion price tag seems excessive, suggesting Adobe overpaid by at least 100%. However, the strategic rationale may lie in preventing competitors like Microsoft or Google from acquiring Figma and integrating it into their ecosystems.

This acquisition offers Adobe an opportunity to reinvent itself. The company has faced criticism for its subscription model, which many view as predatory. By integrating Figma, Adobe can reshape its image and potentially revitalize its product offerings.

One underreported aspect of this acquisition is the potential synergy between Figma's team and Adobe's ongoing projects, such as Photoshop Web and Adobe Express. By leveraging Figma's expertise in web-based, collaborative design tools, Adobe could transition its traditional desktop software to more modern, web-based platforms.

While the acquisition might seem like a simple expansion of Adobe's design software dominance, it could represent a transformative moment for the company. If managed correctly, this could lead to a rebirth of Adobe, much like an inverse of the Lockheed Martin and Boeing scenario. By integrating Figma's culture and innovation, Adobe could add significant value beyond the $20 billion investment.

There's an idea that I can borrow from the startup community, particularly from the Y Combinator crowd, and that's the concept of contrarianism and doomerism. These philosophies often make you seem smart, especially if you're already someone intelligent. They can make you appear insightful and right about things most of the time. However, they don't necessarily make you rich or successful.

Contrarianism and doomerism might enhance your intellectual image, but they won't lead to wealth or success. To achieve success, you need to be a bit delusional and work against the natural entropy of the universe and the world around you. This is something I'm contemplating right now, as the current outlook seems very bleak. Everywhere you look, there are problems.

It's easy for a smart person to predict failures. It's easy to point your finger and say, "This is going to fail," "This is going to collapse," or "This is going to break." However, simply predicting failure won't make you rich or successful.

To truly succeed, you must find a way to be contrarian against the contrarians. You need to discover something where you can snatch success from the jaws of failure and be right about it. When you do, the world will reward you.

We are on the precipice of a boom in hacking by small startups, disrupting medium to large enterprises and established tech companies, especially those backed by venture capital. This shift is starting right now, fueled by recession fears.

What do Chief Marketing Officers (CMOs) do when they face economic headwinds and sales start to drop? Marketing becomes more difficult. I'm not talking about the top 1% of marketers, but the average tech CMO whose entire executive team outsources creativity. Their idea of marketing is to acquire a budget and spend it.

These average tech CMOs look at the economic landscape and recession indicators, acknowledging the high chance of entering a recession. The smart move they make is to consider two strategies:

Think about your target audience and the established product that every other venture-backed company chooses. Position yourself as the cost-effective alternative. Be the product that people switch to, allowing them to report to their bosses that they are cutting costs. For example, switching from Intercom to Crisp could save $1,000 a month.

If you can be that alternative, you can potentially capture a third of the market from your biggest competitors over the next year. While others are minimizing costs and laying off staff, go out there, give it your all, and make some money.

Every founder, at some point, must decide on their marketing platform—the medium through which they will reach their customers. There are several options to consider:

The reason I chose content marketing and SEO is straightforward. It's not that I believe content marketing and SEO are the only worthwhile pursuits. The truth is, I am an introvert. My version of hell is spending every day on LinkedIn, searching for people who might use my product, and then cold emailing them. I've done it, and while it works, it's not something I want to continue doing.

The characteristics of content marketing and SEO suit me better. I want to build something that continues to work over time, regardless of my input. I'm willing to sacrifice quick, immediate wins for long-term gains. I'm okay with that trade-off if it means I don't have to hunt down customers every day and pitch them repeatedly about my business.

Choosing the right marketing platform is about finding what aligns best with your personality and business goals. For me, content marketing and SEO provide a sustainable path that matches my strengths and preferences.

Chargebacks can be a significant indicator that your User Interface (UI) or support process may not be meeting user expectations.

Chargebacks occur when a customer disputes a transaction with their bank, effectively reversing the payment. This often suggests that the customer found it easier to resolve their issue through their bank rather than directly with your service.

Have you ever used your bank's website to initiate a chargeback? It's not known for being user-friendly or quick. If your customers are choosing this route, it may indicate that your support process is introducing too much friction.

If you're experiencing a high volume of chargebacks, it might be time to reassess these areas to reduce friction and improve customer satisfaction.

I've been thinking a lot about Damon's company and a recent experience with a domain auction that got me pondering the complexities of generic domain names and trademarks.

The other day, I stumbled upon an auction for the domain testimonial.TO. It was promoted in a promotional email sent to everyone registered for their aftermarket newsletter. Intrigued, I forwarded the information to Damon, who decided to place the minimum bid. However, the auction turned out to be quite competitive, with two other bidders driving the price up significantly. I won't disclose the final amount, but the aggressive bidding made me suspect that the buyers might have nefarious intentions.

This experience led me to explore the Google AdWords traffic for testimonial.TO-related keywords. I noticed several competitors running ads for terms like "testimonial.TO pricing." This got me thinking about the inherent issues with generic domain names, which can't easily be trademarked.

For most startups, if you raise a decent amount of money, you can invest in trademarking your brand name for about a thousand dollars. This allows you to protect your brand by filing complaints against Google AdWords ads that infringe on your trademark and preventing others from registering similar domain names.

However, with generic names like "testimonial," you can't trademark the word itself. You might be able to trademark "testimonial.TO," but that wouldn't stop someone from registering "testimonials.io" or similar variations. Getting Google to remove such listings could prove challenging.

This situation made me reflect on my own domain registrations. I've registered a few generic domains that I like from a branding perspective, such as "servers.deal." However, I hadn't fully considered the complications of protecting these domains once they mature. Without the ability to trademark them, they remain vulnerable to similar issues.

In conclusion, while generic domain names can be appealing, they come with unique challenges that require careful consideration, especially regarding trademark protection and brand security.

The format of the January 6 hearings is quite intriguing. The use of videos suggests that the production is crafted with a prime-time audience in mind. The creators seem to be aware that the majority of viewers will encounter these hearings through clips reproduced on various platforms, such as nightly news broadcasts, YouTube, or other online media.

A significant portion of the hearings consists of video footage of testimonies from the past year and a half. This choice is noteworthy as it highlights the emphasis on visual storytelling and direct evidence presentation. The reliance on video clips serves to engage viewers by showing rather than telling, which is a departure from traditional hearing formats.

Another compelling aspect of the format is the way each hearing concludes. Liz Cheney provides a "next time on the January 6 hearings" segment, complete with a video clip and a preview of upcoming content. This approach is reminiscent of the ending of a serialized drama, where viewers are enticed to tune in for the next installment. The use of these "previously on" and "next time on" segments adds a narrative structure that is designed to maintain viewer interest.

Interestingly, the hearings predominantly feature Republicans. Most of the time, the arguments are presented by Republicans, and the questions are posed by them as well. This strategy of showcasing testimony, often from individuals within the Trump administration, aims to construct a narrative from their perspective. It is a method of "show, not tell," where the committee members are not overtly pushing their agenda but instead allowing the testimony to speak for itself.

Despite the anticipated criticism labeling the hearings as a partisan witch hunt, the format is meticulously designed to counter such claims. By focusing on video evidence and Republican voices, the hearings aim to make it challenging to argue in good faith that the proceedings are purely politically motivated.

In conclusion, the format of the January 6 hearings is a strategic blend of visual storytelling and narrative engagement. It remains to be seen whether this approach will prove more engaging than previous hearings, but it certainly sets a new precedent for how such events can be presented to the public.

In this follow-up to the JS HTTP virtual file system post, I experimented with a new website using a different data set. This time, I utilized a 10 MB data set of arcade games from the Internet Archive's Arcade project. The data is spread across flash games, categorized under titles and names, and comprises about 11,000 to 12,000 records in a SQLite database. Most of the data is indexed, and I built a view to test the performance.

The CDN performance is outstanding, slightly faster than anything else I've deployed to any CDN I've used. This gives me a good idea of where the system excels and where it might fail. The website is impressively fast, featuring infinite pagination for each category. It loads 30 records at a time using normal paginated SQL queries like LIMIT and OFFSET, making the process almost instantaneous. On a fast internet connection, the loading indicator is practically invisible, with subsequent requests for additional pages taking only about 30-40 ms, which is imperceptible.

However, there's a significant cold start problem. The WebAssembly module must be loaded before the first request, taking anywhere from 900 ms to 1.5 seconds. The module is a 1.3 MB binary WebAssembly file containing the SQLite database driver. This delay can be hidden by using it as a feature, starting the download asynchronously when the webpage loads.

The initial query requires loading about 1.2 MB of the 10 MB database, but subsequent requests are extremely fast, often around 5-10 ms, likely due to caching. For instance, some requests come in at about 40-50 ms for 30 KB of data.

When users land on the homepage, the initial cold start problem can be masked since it occurs asynchronously. The webpage loads in under a second, and the download of the WebAssembly file begins, taking about a second. As long as it takes users a couple of seconds to navigate to their desired category, the experience feels quick and seamless.

Optimizing further might not be feasible with a 10 MB data set. For larger data sets, the cold start problem can be hidden effectively. I considered how this approach might work for platforms like Netflix or HBO Max, where the entire public database of titles could be stored in a database, with URLs to images, descriptions, and titles.

One trade-off is that the data gets cached, potentially consuming a significant amount of memory in JavaScript, equivalent to the entire database size. This could be an issue for platforms like webOS or lower-end Android devices, especially Amazon devices. However, higher-end devices like Apple TV could handle it, though implementing such technology might not be worth the effort due to the need to reinvent everything from scratch.

This technique allows deploying a website directly to a static CDN without worrying about a database server, while still providing the ability to query a SQL database in read-only mode. It's a neat solution with potential use cases, especially in data science for exploring data sets.

I've been experimenting with SQL.js HTTP VFS for a few months now. Essentially, this is a SQLite engine compiled into WebAssembly that can run against a remote database. The intriguing part is that it implements a virtual file system and supports range requests.

Imagine you have a gigabyte-sized SQL database stored in the cloud. As long as your server supports range requests, this setup allows you to fetch data one kilobyte at a time. This is similar to how SQLite would read a local database from the file system if configured to page with file reads of 1024 bytes. The exciting aspect is that if you index and organize your data efficiently, you could theoretically perform the same requests remotely from a browser to a SQL database on a CDN. This means your backend server wouldn't need to run a database instance.

In August, I spent a couple of weekends writing a possible analytics clone using SQL.js HTTP VFS. It was an interesting project, but I didn't delve deeply into it. The implementation cleared a lot of data, almost as if downloading the entire database, so it didn't thoroughly test the concept. However, it served as a valuable proof of concept.

Fast forward to December, I decided to rewrite the project. I started with an injected log parser, ending up with a 300 MB log file, which I parsed into a roughly 300 MB SQLite database. This provided a substantial database to experiment with. The size required me to optimize log parsing and inserts, reducing the time to parse over 1.3 million rows to about 57 seconds. This included parsing IP addresses, country lookups, URLs, and user agents—all done locally without web requests.

Running queries on this indexed database locally resulted in approximately 13-second queries to group by pathname and count requests for the top 25 pages. This wasn't ideal, especially since I only loaded eight hours of data. In a production environment, the dataset would be much larger. Adding a few indexes significantly improved performance, reducing query times to 100-300 milliseconds.

As I was about to implement the WebAssembly module to run everything remotely, I had a realization. What does this setup truly offer? While it allows for scaling the number of reads infinitely, it doesn't make much sense unless you're dealing with massive datasets that can't be pre-computed. For my use case, with only eight SQL queries to run, pre-computing on the server was more efficient.

This project was an intriguing exploration of a virtual file system over HTTP. While it was fun and educational, it didn't present a compelling use case for my needs. Unless you're dealing with scenarios where pre-computing data is impractical, the benefits of this approach are limited. Nonetheless, it was a fascinating experiment that expanded my understanding of remote database querying.