DEV Community: Samir Alibabic

What AI Actually Did to My Software Development Velocity

Samir Alibabic — Thu, 24 Sep 2026 17:29:40 +0000

A lot of AI productivity claims sound impressive until you ask what was actually measured.

"10x developer productivity" usually means one of three things:

More lines of code
Faster task completion in a benchmark
A subjective feeling that work is moving faster

Those are weak signals.

Lines of code are easy to inflate. Benchmarks are not production systems. And generating code quickly is not the same as shipping working software safely.

I wanted a better answer for my own work.

I own and operate MachDuDas, a German marketplace that has existed for more than a decade. The repository has years of history from conventional development teams, before generative AI was part of the workflow.

Today, I am effectively the only human driving development, but I work heavily with AI coding agents.

That gave me something close to a natural experiment:

Same product. Same codebase. Different development model.

The question was simple:

How much engineering capacity have AI agents actually given me?

The first measurement was misleading

My first instinct was to look at code volume.

Over roughly 30 days of recent development, MachDuDas had:

About 54,700 lines added
About 10,000 lines removed
About 44,600 net lines added
139 relevant commits
Another roughly 10,000 net lines on feature branches not yet merged to master

That looked like about 10,000 net lines per week.

If you compare that to old industry estimates for programmer productivity, the result looks absurdly good. Depending on the benchmark, you can make the output look equivalent to a team of 15, 20, or more engineers.

That comparison failed the smell test.

The reason is obvious once you inspect the work.

AI-assisted development produces a lot of supporting code:

Automated tests
Browser tests
Fixtures
Migration logic
Verification scripts
Supporting infrastructure

That code is valuable and cannot be compared reliably with generic historical LOC benchmarks.

A line of application logic, a line of fixture data, and a line of browser-test setup are not the same productivity unit.

So I stopped comparing MachDuDas to generic industry averages.

I compared it to itself.

The better baseline was the same repository

The MachDuDas repository still contains older development history.

That means I can compare current AI-assisted development against earlier conventional development on the same product.

One useful period was July 2016.

During that month, three human contributors added approximately:

22,900 lines of runtime application code

They also removed about:

5,700 lines

That was a productive conventional team working on the same software product.

Now compare that with recent AI-assisted development.

In June 2026, one human contributor directing AI agents added approximately:

30,800 runtime-code lines

In August 2026, runtime-code additions were lower:

About 12,200 lines

But test code exploded:

More than 72,000 lines of tests were added

Across March through September 2026, MachDuDas accumulated approximately:

81,000 runtime-code additions
105,000 test additions

That test number matters.

The older history does not contain anything close to that amount of automated verification.

The fuller story includes:

AI makes certain kinds of engineering work cheap enough that I ask for much more of them.

Especially testing.

The multiplier I can defend

When I normalized the historical periods by active human contributor-month, the current AI-assisted workflow produced about:

2.4x the runtime-code output per active human contributor.

If I exclude the initial large 2016 repository-import period, the multiplier is closer to:

3.2x.

That is much less dramatic than the 10x or 20x claims people like to throw around.

It is also much more believable.

And it only covers application-code production.

The estimate also excludes extra automated QA, migration verification, operational work, and test-writing produced by agents.

My current estimate is that my one-person-plus-agents setup has engineering capacity comparable to a conventional pre-generative-AI software team of roughly:

4 to 7 people.

My best single estimate would be around five or six.

Very roughly, that conventional team might have looked like:

2 to 3 application developers
1 to 2 QA or test-automation engineers
Part of a DevOps or release-engineering role
Part of a technical product or engineering-management role

This is an engineering-capacity comparison. Literal replacement of six developers is too simplistic.

It means one technical founder can now operate at a level of engineering capacity that, on this product, previously would have implied a small software team.

Those are different claims.

Shipping matters more than code volume

The next question is more important:

Did the code actually reach production without making the product worse?

So I reconstructed MachDuDas production deployments and applied DORA-style delivery metrics.

The goal was to look beyond code generation and measure the delivery system:

How long does a commit take to reach production?
How often do deployments happen?
How often do deployments break production?
How quickly do deployment-caused failures recover?
How much deployment work is rework?

This changed the picture.

Lead time changed once large branches cleared

Across a large set of commits where I could reconstruct both the commit timestamp and the first production deployment containing that commit, the median commit-to-production time was:

6.8 days.

The 75th percentile was about:

9.2 days.

At first, that looked much less impressive than the development velocity.

Then I separated the most recent deployments.

From mid-September onward, the median commit-to-production lead time fell to roughly:

11 hours.

The 75th percentile was about:

3 days.

The system had changed.

Earlier work was accumulating in large branches, especially around a major frontend migration and parity project. Once those large batches started clearing, the actual delivery loop became much shorter.

This is an important lesson for AI-heavy development:

Fast implementation does not automatically create fast delivery.

You can generate code faster than you can review, integrate, and release it.

Deployment frequency moved from weekly to several times per week

Over the six-month period I reconstructed, MachDuDas averaged approximately:

One production deployment every 6.8 days.

That is roughly weekly.

But the recent period looked different.

Between September 14 and September 22, there were:

Seven production deployments in nine days.

So deployment frequency moved from roughly weekly toward several times per week.

That is the kind of signal I care about more than raw LOC.

If AI only creates larger branches that sit around longer, the productivity gain is partially trapped.

If it helps produce smaller changes that reach production safely, the gain is much more real.

Change failure rate stayed in a reasonable range

I also reconstructed production incidents and separated them into categories:

Failures clearly caused by deployments
Likely deployment-related failures
Unrelated infrastructure issues
Staging failures
Normal follow-up improvements

That distinction matters.

An nginx outage, for example, is not automatically a failed software change.

Using the strictest interpretation, I found one clearly documented production regression caused by a deployment during the relevant period.

That gives a change failure rate of approximately:

3.7%.

There was another earlier incident that was very likely deployment-related. Including that one raises the estimate to:

7.4%.

So the defensible range is approximately:

4% to 7%.

Given the amount of software changing, that number is more meaningful to me than how many lines the agents wrote.

Recovery and rework matter too

The earlier likely regression was hotfixed in about:

13 minutes.

The later confirmed deployment regression was remediated within approximately:

15 hours.

The historical evidence is not precise enough to claim an exact median recovery time.

But it is enough to say observed recovery from deployment-caused failures was within:

Less than one day.

There were no observed executed rollbacks in the reconstructed period.

I also looked for production deployments whose primary purpose was repairing a problem introduced by earlier deployment work.

Depending on how conservatively incidents are classified, approximately:

7% to 11% of deployments were rework.

That is an important guardrail.

An AI system that writes 100,000 lines and forces humans to spend the next month repairing them is not productive.

Here, the evidence shows high output alongside acceptable delivery quality.

The bottleneck moved

The most important conclusion is that the bottleneck moved as implementation became cheap. Fast code generation is already obvious.

The more interesting change is that the bottleneck moved.

Ten years ago, implementation itself was expensive.

A feature required human time across many layers:

Backend code
Frontend code
Tests
Migration logic
Repetitive verification
Documentation
Debugging
Operational scripts

Every additional layer consumed scarce engineering hours.

Today, many of those activities are much cheaper.

I can ask an agent to investigate legacy behavior, implement a change, write unit tests, add browser tests, test migration idempotency, inspect edge cases, update documentation, and review its own implementation.

Engineering still carries real costs. The scarce resource moves.

The scarce resource is increasingly judgment.

Someone still has to decide:

What should the system actually do?
Is the agent solving the right problem?
Did it invent an unnecessary abstraction?
Is a behavior change intentional?
Should this branch be merged?
Should this deployment happen now?
Is this test proving useful behavior, or just encoding the agent's assumptions?

Those are still human decisions.

Batch size became a real problem

One of the largest recent MachDuDas initiatives accumulated more than 60 commits on a feature branch.

The implementation work was moving quickly.

But the branch became large.

That creates a strange failure mode.

AI can generate changes faster than they can comfortably be reviewed, integrated, and released.

In traditional development, teams often waited for implementation.

In AI-heavy development, implementation can start waiting for acceptance.

That is a different engineering-management problem.

The practical response is to keep the work smaller:

Smaller stories
Smaller branches
Shorter-lived branches
More frequent integration
More frequent production releases

The old advice to reduce batch size becomes more important when code generation gets cheap.

AI changes the economics of testing

The test numbers surprised me.

In one month, AI-assisted development added more than 70,000 lines of tests.

I would not have commissioned that amount of manual test-writing effort from a small conventional team.

It would have been economically irrational.

But if the marginal cost of test creation drops, the tradeoff changes.

The question becomes less:

"Is this worth paying a human to test manually?"

And more:

"Can we prove this behavior?"

If the answer is yes, an agent can often create that proof at relatively low incremental cost.

This is another reason raw LOC comparisons are misleading.

Thirty thousand lines of application code plus seventy thousand lines of tests is not the same thing as one hundred thousand lines of application complexity.

Some of that volume is verification that previously would not have existed at all.

What I would measure on another codebase

If you are trying to evaluate AI-assisted development in your own team, start with delivery outcomes before "lines of code generated."

I would start with these questions.

1. Compare against your own history

Do not compare your team to generic productivity benchmarks if you have better data.

Your own repository history is a stronger baseline.

Same product. Same domain. Similar architectural constraints.

2. Separate runtime code from verification code

Application code, tests, migrations, fixtures, and operational scripts should not all be treated as the same output.

They all matter, but they mean different things.

3. Normalize by active human contributor-month

If you want to estimate human capacity, normalize by the humans actively involved.

Otherwise you are just comparing busy periods with quiet periods.

4. Track delivery alongside generation

Measure whether the work reaches production.

Useful metrics include:

Commit-to-production lead time
Deployment frequency
Change failure rate
Recovery time
Rework caused by previous deployments

5. Watch batch size

AI can make large branches deceptively easy to create.

Large branches remain hard to review and risky to ship.

If lead time gets worse while code output improves, batch size is a likely suspect.

6. Treat tests as output and classify them separately from application complexity

AI-generated tests can be very valuable.

Keep test volume separate from runtime code volume.

Large test additions may reflect improved verification without enlarging the product surface.

Limits of this comparison

Generalizing this into a claim that one AI-assisted founder can replace every six-person engineering team would exceed the evidence.

MachDuDas has characteristics that make AI particularly effective:

It is an existing product
A lot of behavior is already encoded in the software
The repository contains substantial historical context
I know the product well and can make decisions quickly
There is almost no organizational communication overhead
Agents can work directly against the repository
Many tasks involve construction, migration, testing, and verification

A six-person startup building a new product is doing more than writing code.

It is also doing discovery, customer research, design, strategy, internal communication, and countless informal decisions that do not appear in Git.

Those responsibilities still require human judgment.

Where I landed

For MachDuDas, the evidence currently supports this conclusion:

One founder directing AI coding agents is producing roughly 2.5 to 3 times the application-code output per active human contributor that the same product historically achieved with conventional developers.

Once automated QA, testing, migration work, and release engineering are included, the overall engineering capacity appears comparable to roughly:

A 4 to 7 person conventional software team.

Delivery quality remained stable enough to make the additional throughput useful.

Recent production delivery has reached:

Sub-day median commit-to-production lead time
Several deployments per week
Approximately 4% to 7% observed change failure rate
Recovery from deployment-caused failures within a day
Relatively limited deployment rework

Those numbers will change as more data accumulates.

But they tell a more useful story than LOC alone.

The practical implication for technical founders

The biggest change is the amount of software business one technical founder can now maintain and substantially evolve. Typing speed barely matters to me.

A technical founder can now direct a collection of AI agents that investigate, implement, test, and verify software across multiple layers of a system.

The founder becomes less like an individual programmer and more like a very small engineering organization.

But somebody still has to run that organization.

Someone has to maintain the model of what the product is supposed to do.

Someone has to notice when an agent is technically correct but solving the wrong problem.

Someone has to decide what goes into production.

Someone has to say no.

For now, that is still the human job.

And in my experience, that is where the real leverage now sits.

Free and Open-Source alternatives to Bitly and Co.

Samir Alibabic — Sun, 31 Mar 2024 12:59:17 +0000

In my Introduction to Link Shortening I gave an overview of the most popular solutions for link shortening and management. This time I want to introduce you to some of the alternatives to popular services like Bitly, which are free, Open-Source and can be hosted on your own servers.

Polr

Polr is a PHP-based, open-source link shortener, with an API access and basic analytics. While its user interface may have charmed users back in 2013 at the project's inception, it now falls short of contemporary design standards.

On the analytics front, this link shortener furnishes insights into visits, referrers, and the geographical distribution of visitors. It has a demo version online, which you can test, before you decide to install it on your server.

I decided to give it a whirl myself, but after poking around in the demo, I didn't even bother with the hassle of installing it on my own machine.

However, it's worth noting that Polr isn't packaged within a container, necessitating manual setup. Nonetheless, for those willing to undertake the effort and requiring only basic analytics, the project is readily available on GitHub, where it garners a commendable 4.9k stars.

YOURLS

Originating in 2009, this link shortener stands as one of the oldest in the field. Developed in PHP, it boasts a robust ecosystem comprising over 200 plugins designed to expand its functionalities.

Despite my attempts to deploy it within various containerized environments - via Docker image on a Lima machine, both with and without docker-compose and later within a Minikube environment using Helm - I encountered persistent setbacks. Whether due to my own missteps or shortcomings in the Docker image's accuracy or currency, I found myself unable to achieve a successful deployment.

Compounding this challenge, as a macOS Sonoma user, I faced the additional hurdle of PHP support removal. To circumvent this limitation, I resorted to manual installation. Employing the familiar brew install php command, which I rely on for most software installations, I obtained the necessary instructions to integrate PHP with Apache:

To enable PHP in Apache add the following to httpd.conf and restart Apache:
    LoadModule php_module /usr/local/opt/php/lib/httpd/modules/libphp.so

    <FilesMatch \.php$>
        SetHandler application/x-httpd-php
    </FilesMatch>

Finally, check DirectoryIndex includes index.php
    DirectoryIndex index.php index.html

However, upon executing the instructions, macOS Gatekeeper intervened, flagging the module as unsigned. While I won't delve into the intricacies here, you can refer to a comprehensive guide provided in a Medium article for detailed instructions. Feeling overwhelmed by the complexity of the process, I made the decision to pivot and explore alternative solutions.

Nevertheless, the project continues to receive active maintenance from its creator, Ozh Richard, and boasts a thriving community of contributors. Its source code is readily available on GitHub, where it has garnered an impressive 10k stars, indicative of its widespread adoption and popularity within the developer community.

Kutt

Kutt represents a sleek, contemporary option, delivering a robust user experience alongside an array of appealing features. Among its highlights are customizable short URLs, comprehensive click tracking, and detailed analytics.

Under the hood, Kutt's tech-stack includes Node.js with Express, Passport for authentication, React with Next.js for frontend rendering, Easy Peasy for state management, styled-components for CSS styling, and Recharts for chart visualization. Data storage is handled by PostgreSQL, complemented by Redis for caching, while deployment is streamlined through Docker.

It boasts browser extensions, a handy CLI, and versatile clients and SDKs for almost any platform you can think of. Plus, it plays nice with ShareX, the ultimate screen capture and file-sharing tool.

However, as of writing this, the hosted version at kutt.it seems to have taken a hiatus. Moreover, its development pace has slowed down, and its tech-stack isn't exactly keeping up with the times. Attempting a manual installation via npm was a headache, thanks to pesky dependency conflicts, leaving Docker as the only viable option.

Even after firing it up in Docker, creating an account proved to be an exercise in futility, with the UI offering nothing more than a vague An error occurred message. Call me lazy, but I wasn't keen on diving into container logs and hunting down root causes. Nevertheless, I'm sure with a bit more effort, one could get it up and running smoothly.

It's open-source under the MIT license, living its best life on GitHub with a respectable 8k stars. And hey, word on the street is that the maintainer's already cooking up a version 3.0!

Shlink

Shlink is a self-hosted URL shortener offering a REST API and a CLI interface for interaction. It also includes a Progressive Web Application (PWA) for interacting with multiple Shlink instances.

Similar to Kutt, Shlink can be run via Docker with an internal database. The only requirement is an API key for GeoLite2, used for geolocation data.

To test Shlink locally with ease, Docker users can simply execute the following command:

docker run \
    --name my_shlink \
    -p 8080:8080 \
    -e DEFAULT_DOMAIN=localhost \
    -e IS_HTTPS_ENABLED=false \
    -e GEOLITE_LICENSE_KEY=your_license_key \
    shlinkio/shlink:stable

This command initiates the Shlink server, encompassing both a REST API and a CLI. Subsequently, you can utilise the CLI to generate your API key:

docker exec -it my_shlink shlink api-key:generate

When experimenting with the CLI, if you create a link using the command docker exec -it my_shlink shlink short-url:create, the resulting short link may not include the default port 8080. Therefore, you have to add it manually for the link to work (e.g. http://localhost:8080).

Additionally, the PWA, commonly used for accessing Shlink, can also be installed and operated via Docker by executing:

docker run \
    --name shlink-web-client \
    -p 8000:8080 \
    -e SHLINK_SERVER_URL=http://localhost:8080 \
    -e SHLINK_SERVER_API_KEY=your_generated_key \
    shlinkio/shlink-web-client

Upon visiting http://localhost:8000 you will be greeted with a user-friendly Web App interface complete with analytics. What I find cool by this link shortener is the ability to manage multiple servers within a single interface. 😎

Besides the number of visits for each link, the provided analytics include operating systems, browsers, referrers, countries and cities. Data series can be shown for any period, from one day to a year or custom ranges.

Other interesting features include QR code generation, redirection rules based on devices, languages or query parameters, editing short URL's after creation and comparing statistics for up to five short links. And all this is just on the first glance at the Web App, and there is more. Very powerful!

All the kudos to the author and maintainer Alejandro Celaya, who has been building the project actively since 2016! 🤯

It's definitely underrated with 2.7k stars on GitHub, considering everything this link shortener offers. For those interested, you can check out the repository here: https://github.com/shlinkio/shlink ⭐️

Dub.co

For those in search of a contemporary solution for link shortening and analytics, Dub.co is worth considering. When you visit this hosted service, you'll immediately notice its modern and user-friendly design, which is typical of today's startup landscape.

Dub.co boasts a modern tech-stack, including Next.js, TailwindCSS, Prisma, NextAuth.js, and BoxyHQ for authentication, alongside Turborepo as a robust build system. It follows a cloud-first approach, utilizing various managed services:

Clickhouse database, managed by Tinybird - used for time-series click data
Redis database, managed by Upstash - for caching link metadata and serving redirects
MySQL database, managed by PlanetScale - for storing the actual user and link data
Whether you choose to deploy it locally or integrate it into your existing infrastructure, you'll need to create accounts with the mentioned service providers. Furthermore, you can use Postmark for sending emails and Unsplash to customise your OpenGraph images.

There is no Docker image, but installation is smooth nonetheless, thanks to a nice looking documentation powered by Mintlify. The only issues I ran into, while setting it up locally, were missing POSTMARK_API_KEY (optional according to the documentation) and @dub/ui and @dub/utils modules not building properly. But it was nothing an average technical user can't solve.

Analytics provide visits, referrers, locations by country or city, devices, browsers, and operating systems. Essentially, it covers everything you might need to effectively track your campaign's performance. What I found the most impressive with Dub.co is its extensive options for link creation: UTM parameters, custom social media cards, link cloaking, password protection, expiration date, iOS, Android and Geo-based targeting. It's all there! 🤯

Steven Tey has done an outstanding job with Dub.co, and its success is evident from its recent launch on Product Hunt. Dub.co quickly rose to become 1# Product of the Day and 1# Product of the Week. With its continued momentum, it's well on its way to being a #1 Product of the Month. This significant recognition is sure to propel Dub.co to even greater success in the future.

Dub.co is licensed under the AGPL-3.0 license and has garnered an impressive 15.7k stars on GitHub. 👏

linktracker.info

This article would not be complete without me mentioning my own take on link shortening and analytics: LinkTracker.

It features a simple interface to create and organise short links. Links can be categorised and tagged. Analytics are similar to what we have seen with other link shorteners: visits, browsers, devices, referrers and countries.

All shortened links are managed in a single table view, with statistics shown below. Currently, statistics are aggregated for all the links, except for visits, which are the most important statistic and therefore also shown for individual links.

Tech-stack is Next.js, TailwindCSS and AntDesign. Data is stored in a PostgreSQL database managed by Supabase, with Prisma serving as the ORM.

It's completely free to use and you can try it at https://linktracker.info. 🙏

Unshorten - just in case

As with any link shortening service, it's essential to consider the potential risks associated with spam and security vulnerabilities. Open-source solutions often offer greater transparency and security assurances.

If you ever encounter a short link and have doubts about its legitimacy, you can utilise the free "unshorten" tool available at unshorten.me. This tool helps you expand shortened links, providing insight into their destination and assisting in verifying their authenticity.

Awesome list

If you find this topic intriguing and wish to delve deeper, I highly recommend exploring the "awesome" list on GitHub dedicated to link shortening and management tools.

Thank you for taking the time to read this far. I hope you found the information useful. Feel free to reach out if you have any further questions or feedback. ✌️

How I Built a Link Management Tool MVP in 4 Weeks with the Help of AI

Samir Alibabic — Tue, 26 Sep 2023 10:31:34 +0000

Approach to product development

As an indie developer, you have the freedom to explore your creativity, but the challenge lies in selecting an idea that's not only viable but also achievable when working solo. Ideally, it should be something that aligns with your interests, to keep you motivated and focused.

I've often found myself overwhelmed by the sheer amount of work it takes to bring a concept to life, from brainstorming ideas to coding and finally getting it into the hands of users. Not to mention the knowledge and skills you have to acquire to be able to implement all of it.

Luckily, in 2023, AI is advanced enough to assist us and speed up the whole process. Let's explore together how it can help.

Brainstorming Ideas

I had a few years of experience working as a software developer, and my interests spanned across tech, finance, aviation, space, and gaming. The vastness of these interests left me pondering over the right niche.

To tackle this, I turned to ChatGPT for assistance. The goal was to find a project that I could develop quickly, test in the real world, and iterate on as needed.

The prompts were engineered in such a way as to take into account my background, personal interests, knowledge, and skills. The AI considered factors like market trends, user needs, and competition, which helped narrow down the possibilities.

The first idea AI came up with, was an educative 👩‍🎓 financial 💸 simulation game, FinSim 🏦.

Money, money, money,

Must be funny

I found the idea appealing, but at the same time, I was a little skeptical about whether I could pull this off. It was supposed to be educational, but I wasn't an expert and I didn't have time to become one. It was just too much, even with AI as an assistant. So I said:

Let’s focus on something minimal, which could potentially be used or needed by lots of people online, a web or mobile app, that can be created (at least MVP) in a few weeks.

Selecting a Viable Idea

And that's how LinkTracker was born. It's a link shortener, management, and analytics tool, in the form of a web application designed to help users manage, optimize, and track the performance of the links they share online. This idea had several advantages:

Relevance: Link management is a ubiquitous need, not limited to any specific industry or niche. Anyone who shares links online could benefit from it. (Mistake #1)
Passive Income Potential: While the initial development required effort, the tool had the potential to generate almost passive income through subscription plans or ad placements. (Mistake #2)
Interest Alignment: The project aligned with my interests in tech and web development, making it a project I could stay passionate about.

Defining the MVP

The focus was on delivering fast, following a Lean approach to validate ideas quickly. With the idea in place, the next step was to define the Minimum Viable Product (MVP). AI played a crucial role in this phase as well. It assisted in creating a structured roadmap for development and prioritizing features based on their importance and feasibility.

AI-Driven Feature Definition

Link Shortening: One of the core features of LinkTracker is the ability to quickly shorten links and copy them to the clipboard.
Tag and Category Management: AI suggested a feature for adding tags and categories to links. Users could either create new tags and categories on the fly or select from existing ones, simplifying link organization.
Automatic Title Generation: To enhance user experience, AI suggested generating titles for links based on the linked webpage's title.
Timestamps: The fields like "created by," "created at," and "modified at" were populated without manual intervention.

💡 And that's how you come up with ideas for a specific niche or market, without having insider knowledge. AI, even in its primitive form, has it!

This is a simple example, and after some research and googling, everybody can come up with some features. But, remember, this is a LLM neural network, which was fed vast amounts of data, on any topic, and it always gives the most relevant topics.

I like to think of it like a tag cloud, where tags are whole, dynamically generated paragraphs of text, and you can tap into this knowledge cloud without doing the research yourself.

Selecting the Right Technologies

Choosing the right technologies is crucial in any development project. I opted for a combination of technologies that suited the project's requirements and my familiarity with them.

Frontend: Instead of starting from scratch, I decided to use a SaaS starter kit called Nextacular, built on Next.js. It provided a multi-tenant app structure with Prisma, TailwindCSS, and Stripe integration out of the box. For UI components, I opted for Ant Design, a design system that had most of the components I needed.
Backend: To streamline backend development, I utilized Next.js's ability to create REST APIs. I also deployed the application on Vercel, ensuring an efficient developer experience. For the database, I went with Supabase, a Backend-as-a-Service solution built on PostgreSQL. Prisma served as the ORM to interact with the database.
AI Assistance: Amazon CodeWhisperer was instrumental in writing code snippets, especially in areas where I wasn't entirely familiar with the technologies involved. ChatGPT played a pivotal role in proposing features for the MVP, defining the backlog, and setting sprint goals. The AI was adept at managing the project, while I guided it to better fit my needs and schedule.

💡 To deliver fast, utilize open-source software, starter kits, and known technologies. For learning and exploring new technologies, use AI.

Weekly Progression

The development process was divided into weekly sprints. Here's a summary of the weekly progression:

Week 1: Infrastructure and Database Setup

Set up a local development environment and version control
Configure and adapt Nextacular for my use case
User registration and authentication via SendGrid (E-Mail)
Create a database schema to store link-related information

Week 2: UI and Core Features

Build the user interface for managing and organizing links
Implement link-shortening functionality to generate shortened URLs
Deployment to Vercel and CI/CD setup

Week 3: Link Performance Analytics

Update database schema to capture and store performance data
Enhance UI with analytical data: browsers, devices, referrers, and countries

Week 4: Legal compliance, Product Launch and User Feedback

Drafting and publishing legal documents
Launching the MVP into a public beta
Gathering user feedback and implementing improvements

Costs

When embarking on the journey of product development and idea validation, one critical element to consider is cost management. It's paramount to keep expenses to a minimum, especially before your product starts generating revenue. The pitfalls of ignoring this aspect are evident in the stories of numerous indie builders and startups that faced financial struggles, and, in some cases, even accumulated debt due to uncontrolled costs.

Now, let's talk about LinkTracker's costs. How much does it cost to run this platform? Is it $10 per month, $150 per month, or perhaps a whopping $2500 per month? The answer may surprise you:

$0 per month.

Yes, you read that correctly – zero dollars for hosting and maintaining a fully functional web application. The only recurring expenditure is a mere $20 per year for the domain. 😁

You might be wondering how this is possible. The secret lies in the strategic choice of technologies. If you delve a bit deeper, you'll discover that all the services employed in the LinkTracker ecosystem offer free initial tiers, which aligns perfectly with the needs and budget constraints of startups and indie developers.

Conclusion

From idea generation to feature definition, technology selection, and weekly progression, AI played a pivotal role in making the development of LinkTracker a reality in just a few weeks.

However, having another tool in your arsenal does not make you immune to making mistakes. Besides coding mistakes while using new and unknown tech, here are the two mistakes or wrong assumptions I made when selecting a viable idea:

relevance and
passive income potential

While it is true, that anybody who shares links online, can benefit from a link management tool, people rarely bother. It's only when it's their job, and it becomes tedious and cumbersome, that people turn to tools. For me, that meant, it was not for everybody and I had to find a focus group. That was mistake #1.

💡 Only because I find it useful, does not mean there is a market for it.

Whenever you build something for the people, you can be sure they will come back with questions. That means, client services and support. 🙄 Assuming it will run on autopilot without any effort was my mistake #2.

💡 As software developers, mostly focused on our code, we forget to see the bigger picture in which software is just a single cog ⚙️ in a complex business machine 🚜.

I embarked on the indie development path to fuel my growth as a software developer. In my view, every developer, regardless of their background, should work on side projects to expand their horizons.

LinkTracker's creation was an invaluable learning experience, even without immediate financial gains (yet 😈). No regrets here.

My future holds exciting prospects: crafting new ideas, enhancing product visibility, networking with industry leaders, and soaking up knowledge in business, marketing, sales, startups, and cutting-edge tech.

AI has revolutionized development, making complex tasks more manageable. Whether you're an aspiring indie developer or someone with a great idea, consider AI's potential to supercharge your project.