
## Introducing Contact Card Generator

In today’s digital age, traditional paper business cards persist despite their environmental impact and tendency to get lost or discarded. Here’s a simpler, greener solution.

Transform your contact information into a scannable QR code instantly. No apps or subscriptions required!

### Why QR Codes?

While phones offer built-in contact sharing [features](https://support.apple.com/en-in/guide/iphone/iph1b6c664b7/ios), they often mix personal and professional information. Our generator lets you create dedicated business contact cards, sharing only what you want others to see.

### How It Works

1. Go to [Contact Card Generator](/contact-card-generator)
2. Fill in your details
3. Add a photo (optional)
4. Generate your unique QR code or download a VCF
5. Save or share (only on iOS) instantly
6. Show the QR code for your contacts to scan from their phone’s camera
7. Send your VCF file via WhatsApp, Email, Messages, etc.

Note that due to limitations of QR codes, your photo will not be transferred. VCFs do embed your photo.

#### Pro Tip

> Save the QR code in the Files app & create a shortcut for quick access 

[https://www.youtube.com/embed/-8OxmJF3Eco?si=TjOCo0pcMapYw1zH](https://www.youtube.com/embed/-8OxmJF3Eco?si=TjOCo0pcMapYw1zH)
<br />

#### Pro Tip

> If you’re on an iPhone, you can [add a QR code scanner to control center](https://support.apple.com/en-in/guide/iphone/iphe8bda8762/ios). This will allow you to quickly scan QR codes from your phone’s camera.

[https://www.youtube.com/embed/tgakuPQXHVk?si=iSJRZgqoS4cpeBU8](https://www.youtube.com/embed/tgakuPQXHVk?si=iSJRZgqoS4cpeBU8)

## Make the Switch Today

Join the movement toward sustainable networking. Your contacts (and the trees) will thank you.

For those still using physical cards, consider printing your QR code on the back - it makes a lot easier for folks to save your contact information by scanning the QR code.


Introducing our Contact Card Generator - a simple yet powerful tool designed to modernize business networking while reducing paper waste. By generating a custom QR code containing your professional contact details, we’re making it easier than ever to share your business information digitally. No more carrying stacks of paper cards or mixing personal and professional contact details on your phone. Simply create your QR code once, save it to your device, and share it effortlessly whenever needed. Whether you scan it directly or download the VCF file, your professional connections can instantly save your contact information to their phones. It’s our small contribution to making networking both smarter and more sustainable.

Introducing Contact Card Generator


## Glossary

Before we dive into the topic, let's first understand some of the terminology that we will be using throughout this post.

- [Gradle](https://gradle.org/) is a build automation tool that is used to build, test, and package software written in Java, Kotlin, Groovy, Scala, or any other JVM language. In layman terms, just think of it as a wrapper around the language compiler that adds some extra functionality to make it easier to build and test your software.
- Dependencies are the libraries that your project depends on. Think of these as a set of useful code bundled up together that your project can use, instead of rewriting it everytime it is required.

## Introduction to Version Catalogs

Generally, in a Gradle project, when you want to use a dependency, you need to define the following things:

- The group of the dependency
- The name of the dependency
- The version of the dependency

For example, if you want to use the [OkHttp](https://square.github.io/okhttp/) library, you would define the following:

```kotlin
dependencies {
    implementation("com.squareup.okhttp3:okhttp:4.9.3")
}
```

Now, if you want to use the same library in another module of your project, you will need to make sure that you are using the same version of the library, or you might face compatibility issues.

This can still be resolved by defining the version of the dependency in your project's `gradle.properties` file, like this:

```ini
okhttpVersion=4.9.3
```

and then referencing it in your `build.gradle.kts` file:

```kotlin
dependencies {
    private val okhttpVersion: String by project
    implementation("com.squareup.okhttp3:okhttp:$okhttpVersion")
}
```


This is a good solution, and does solve our issue to a certain extent, but once you have to manage multiple projects, it becomes quite cumbersome to make sure that the versions are consistent across all the projects. Let's take a scenario where:

- You have a set of functions that provide useful abstractions over the OkHttp library, and you use them in multiple projects.
- To make it easier to manage these sets of functions, you decide to create a separate project that contains the functions that are common across all the projects, and you name the library `common`. This library uses OkHttp version `4.9.3` as its dependency.
- In your project, you import the `common` library, but instead of using the version `4.9.3` that you are using in the `common` library, you use the version `4.10.0`.

The given scenario might lead to the following issues:

- The `common` library might not be compatible with the version of OkHttp that you are using in your project, which results in either a compilation error or a runtime error.
- You might not be aware of the OkHttp version that you are using in your `common` library, and assume it's using the same version as your project, which might not be the case. This can lead to you not realizing that you are using an outdated version of OkHttp, which can result in security vulnerabilities in your code.
- Every time you update the OkHttp version in your `common` library, you need to update it in all the projects that use the library, which can be a tedious and time-consuming process.

__Here comes `version catalogs` to the rescue.__

A [version catalog](https://docs.gradle.org/current/userguide/version_catalogs.html) is a selected list of dependencies that can be referenced in a Gradle build script in a type-safe manner.

To explain it in developer terms, think of it as a file where you mention all the strings required by the project, so that instead of mentioning the same string again and again, you can just reference it from that file, with auto-completion support as icing on the cake. It also helps that every time you need to update that string, you only need to do it in one place, instead of updating it in multiple places.

## Using Version Catalogs in Gradle

Version catalog is defined in a file called `libs.versions.toml` in the `gradle` directory of your project. The `libs.versions.toml` file has four sections:

- `[versions]`: Declare versions of the dependencies. If you have a set of libraries which belong to the same group, instead of mentioning versions for them separately, you can define them in a single place, and reference it for all the libraries for which it is applicable.
- `[libraries]`: Here you can define the group, artifact, and version of the libraries that you are using in your project. For version, you can either mention the version directly, or you can reference a version from the `[versions]` section.
- `[bundles]`: If you have a set of libraries that are commonly used together, you can define them as a bundle, and import the bundle in your project. Gradle will check which libraries belong to that bundle, and import them all.
- `[plugins]`: Define plugins that you are using in your project. This is different from the `[libraries]` section, because plugins are not libraries, and instead of consisting of a group, artifact, and version, they consist of an id and a version.


An example `libs.versions.toml` file would look like this:

```toml
[versions]
okhttp = "4.9.3"

[libraries]
okhttp-core = { group = "com.squareup.okhttp3", name = "okhttp", version = "4.9.3" } # mentioning the version directly
okhttp-logging = { group = "com.squareup.okhttp3", name = "logging-interceptor", version.ref = "okhttp" } # referencing the version from the okhttp version

[bundles]
okhttp = ["okhttp-core", "okhttp-logging"]

[plugins]
kotlin-jvm = { id = "org.jetbrains.kotlin.jvm" , version = "1.9.20" }
```

To use the version catalog in your project, you need to add the following lines to your `build.gradle.kts` file:

```kotlin
plugins {
    alias(libs.plugins.kotlin.jvm) // to use the kotlin-jvm plugin
}

dependencies {
    // You can either import the libraries separately
    implementation(libs.okhttp.core)
    implementation(libs.okhttp.logging)
    // Or as a part of a bundle
    implementation(libs.bundles.okhttp)
}
```

## Publishing Version Catalogs

So far, we have seen how to define version catalogs in a `libs.versions.toml` file, and how to use them in a Gradle project. However, this still does not solve the inherent problem of managing dependencies across multiple projects. 

Fortunately, you can publish your version catalog, just like any other library! To do that, you need to import the following plugins:

```kotlin
plugins {
    `version-catalog`
    `maven-publish`
}
```

This will allow you to configure your version catalog, and configure `maven-publish` plugin to publish the catalog, like this:

```kotlin
catalog {
   versionCatalog {
       // Import the version catalog from the libs.versions.toml file
       from(files("${rootProject.projectDir}/gradle/libs.versions.toml"))
   }
}

publishing {
    publications {
        create<MavenPublication>("maven") {
            from(components["versionCatalog"])
            artifactId = "version-catalog"
            group = "com.yourgroup"
            version = "1.0" // or a version from a configuration file
        }
    }
}
```

Now, along with your `common` library, you can import the version catalog in your projects, and use the same version of the OkHttp library that you are using in the `common` library.

Add this to your `settings.gradle.kts` file:

```kotlin
dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
            from("com.yourgroup:version-catalog:1.0")
        }
    }
}
```

Voilà! Your version catalog is ready to be used in your project:

```kotlin
dependencies {
    implementation(libs.okhttp.core)
    implementation(libs.okhttp.logging)
}
```

Now, every time you update the OkHttp version in `common` library, you only need to update your library version in the project, and the OkHttp version will automatically be updated!

> But what if you want to use a library, that is not a part of version catalog?

In that case, you can customize the version catalog at the project level to include the library that you want to use:

```kotlin
dependencyResolutionManagement {
    val log4jToSlf4jVersion: String by settings
    versionCatalogs {
        create("libs") {
            from("com.yourgroup:version-catalog:1.0")
            library("log4jToSlf4j", "org.apache.logging.log4j:log4j-to-slf4j:$log4jToSlf4jVersion") // log4jToSlf4jVersion is defined in gradle.properties
        }
    }
}
```

Later you can add this library to your version catalog if you want this to be used across projects.

> Can we publish the `common` library as a part of the version catalog?

Since the `common` library is getting published along with the version catalog, we would need to make sure that the library version is updated in `libs.versions.toml` with every release.

To avoid this, you can define the `common` library not as a part of `libs.versions.toml`, but as a part of the version catalog Gradle plugin, like this:

```kotlin
catalog {
   versionCatalog {
       // Import the version catalog from the libs.versions.toml file
       from(files("${rootProject.projectDir}/gradle/libs.versions.toml"))
       library("common", "com.yourgroup:common:$version")
   }
}
```

Where you can dictate how the `version` is defined (environment variable, property, etc.).

## Conclusion

We have seen how to define version catalogs, and how to use them in a Gradle project. Instead of spending days updating each and every dependency manually across projects, you can reduce the effort to just a couple of hours!!

Additionally, to reduce the time even more, you can use a plugin like [version-catalog-update-plugin](https://github.com/littlerobots/version-catalog-update-plugin), which will automatically update the version of your dependencies to the latest version available that it can find. However, be careful while using such plugins, as sometimes they might update the version to an unstable one, which might not be desirable for your project.

Hope you found this post helpful!


Managing dependencies of your project is something that no one wants to do, but it is a necessary part of developing a project. When you have a set of runtime libraries that you need to use accross multiple projects, it becomes quite challenging to make sure that your project is using the correct version of the common dependencies between the library and the project. In this post, we will take a look at what version catalogs are, how they can help you simplify dependency management, and how you can use them in Gradle.


Simplifying Dependency Management Using Version Catalogs in Gradle

## Two Common Pitfalls Identified, Which Any Team May Encounter

- Assuming that everything the client had listed must be included in the MVP
- Mistaking precision for accuracy

Let‘s break these down further & see what we learn!

### Assumption: Everything Listed Is Part of the MVP

Clients often come with a broad list of features they envision for their product, though these are often high-level and not fully thought through. While such input is valuable, it’s essential to focus on zing features for a Minimum Viable Product (MVP), ensuring a incremental approach to delivery rather than attempting to include everything at once.

An MVP is about identifying and prioritizing the *‘must-haves’* that will provide value early, allowing the product to have early launches with iterative improvements. Simply including all client requests without filtering or questioning the *‘why’* behind each feature can lead to bloated scopes, extended timelines, and unnecessary complexities.

The role of the team is not just to deliver what is requested but to refine the client’s vision. This involves asking questions, analysing feasibility, and offering alternative solutions that align with business goals. By doing so, teams can help clients achieve *‘faster time-to-market’*.

### Mistaking Precision for Accuracy

Another challenge arises when teams focus on precision rather than accuracy in their estimates.
- **Accuracy**: Saying, “This feature will take about a week to implement”, keeps expectations reasonable.
- **Precision**: Claiming, “This feature will take exactly 34 hours”, might seem confident but is less likely to account for changes or setbacks.

In early project planning, focusing on accuracy allows teams to provide high-level estimates that guide decisions effectively without creating rigid or unrealistic expectations. Precise estimates at this stage, while detailed, can mislead and slow down progress if they don’t align with evolving project details. By doing this, teams fosters more productive conversations with clients, enabling them to make informed decisions faster.

## Key Takeaways

- Always question and refine client requirements to deliver the most value.
- Remember, an MVP is about *‘minimal effort’* with *‘maximum viability’*.
- Prioritize *‘accuracy’* over precision in early-stage estimations.

Estimation is more than a technical exercise; it is a collaborative process between the client and the team which requires questioning and a clear focus to deliver faster, but with something that holds value. 


Effective early-stage estimation goes beyond calculating numbers—it’s about refining client visions, questioning assumptions, and setting realistic expectations. Challenges like assuming all client-listed features belong in the MVP or mistaking precision for accuracy can derail progress. This blog shares lessons learned, emphasizing prioritizing value-driven features, adopting an iterative approach, and focusing on accuracy over precision to streamline early project planning.

Stories From the Trenches