Blog

iSha: Pronounced as Aisha.

My daughter, Aisha, was born in 2022. As a new parent, I was very cautious over everything and I wanted to get an overview of what was happening, was I a good parent, were we being supportive for our 2 day old baby? I had a concern regarding Aisha’s health in the first week and I took a photo of Aisha. The photo was purposefully taken just to show the doctors whether my concerns were real or not, and what to do.

2 days later I was surfing my Photos app and I saw Aisha’s photo there. I would not have wanted this picture to make its way in such an environment, be cloud synced, or be leaked. It was at that day that I decided that I would make an application that would allow parents to track and share the data of their children in a controlled manner. And there is nothing as controlled as the one that does not interact with a server. Humans make mistakes, machines make worse mistakes. The app could potentially leak the data to a server, whether by human mistake or intention. The server could log the data, or someone else could get access to it. It is best to avoid this in the first place and make a conscious choice to only export the data that you require. Thus, effectively making an enclave for the data for your babies.

That idea turned into an app for parents, and today I happy to share that the application is ready to download and use.

The app

I started working on the app back in September 2022, and with the little time I could find to work, I would add one or two features that would mainly create the structure for the database to store the information but ensure that the data would be stored privately.

The objective of the application is very simple.

• Offer the parents with a simple to use application where they can log the data for their baby’s growth.
• Follow a guided, reminding flow for their babies. Where they can create reminders for their babies.
• The application must be private. The features must be modern and up to date.
• Offer data import/export services to allow parents to share the data that they would like to share with others.

The application is developed using Flutter, and offer services without creating an account. You will not need to create an account since there is no need to sync the data. As part of the roadmap, I am working on adding support to share the data from one device to another, one partner to another, and perhaps (if needed by the users) to share data with nannies and caretakers. However, since we will not support servers, the technical opportunities would need to be explored and decided on.

In the meantime, the app is ready for users. Here is a gallery that shows the application interface and features.

The application is also designed to support bigger screens (tablets for now).

Where to download?

You can download the app from the Play Store and the App Store. The application is available on Android and iOS platforms. It is a free application, of course, and is privacy-first by default.

The application is available on Play Store and App Store.

Please consider giving it a go, and share any feedback you may have. Any feedback, suggestions, questions, or concerns are welcome.

As is shared, the app is created by a parent for the parents and the objective is never to use the data of your babies for any purposes. Your children deserve the privacy, and the app will commit to delivering it.

Where do the AI-platforms exist in the stack vertical of an application?

Historically, we refer to our tech stack and base its sorting on how much a particular runtime/framework is going to be customer-facing vs internal. For example,

1. A mobile application that allows users to save the links to read later and also share with others in their contacts.
   • For such an application, you would automatically sort the frameworks by the mobile app, then any middleware or a mobile-backend.
   • If you write your own backend and business logic, then you would add that as well.
2. A web application that allows users to track their monthly grocery expenses.
   • The framework by default gets priority; .NET, Spring, or some other web application development framework.
   • Even though you do build an interface for the customers to use, you put it secondary, because your business is around the API and not the way that this list is communicated to the customers.
3. A B2B API gateway that allows one company to manage fulfillment services for another company.
   • You would put multiple frameworks as a priority and a must have.
   • You would avoid onboarding an engineering that does not have the big picture in their mind.

Imagine these three organizations; technically, they all have a backend, a “frontend” and a data storage. The infrastructure would have firewalls for security, load balancers for optimization, and what not. But, it doesn’t take away the fact that each of these services has a server that processes the business logic, an interface for the customers and clients to access the services, and a central storage where everything is kept for the time it is needed to be kept.

Tech Stack Communication

Nobody writes IIS, or Apache, or other server components in their tech stack. Why? Is there not a “production-ready” server that must be communicated to the customers? I can understand hiding the version-specific information in some cases to prevent bad actors from misusing, but it’s well known that most Microsoft-based web applications are hosted on IIS and others on Apache (PHP, Java, etc.). So why is it that the most crucial piece is left out?

The important point to remember and consider is that it is not the Apache server that the engineers and developers are going to program and write the business logic on. It is infact the underlying server-side code framework that they will need to program. ASP.NET, Spring, Express (or even Node.js in some cases) is the actual layer that your developers will most concern with. That is why, it is important that you have someone who is an expert in ASP.NET or Spring, and not someone who is great at IIS or Apache Tomcat.

The top reason that comes to mind for the tech stack communication is:

• To make it easier and simpler for the next engineers to onboard and expect the tech culture of a project or a team.
  • It is entirely true and possible that two teams in the same organization have different cadence for release, a different culture for git-blame, a special way of writing and accepting the changes.
• To make it clear and reasonable why certain development tooling choices were made and how they contribute to the overall ecosystem of the technical products.

When you share the tech stack, you are also exposing your own preferences as to what you believe is important and what is less important. When you say that your application uses:

• Flutter, TypeScript, Firebase, Git

You are explicitly making it clear to any reader that you are not going to compromise on Flutter for app development, TypeScript for backend development, Firebase for mobile-backend (database, authentication, analytics, etc.) and Git as a version control system. For everything else you are open. For example, in a mobile application we would need to use a state management system. In Flutter, we can use either the native state management support or use provider and other complex state management systems. Flutter does not force us, and by keeping this hidden, you are indicating that this is up for a debate. If someone has a better idea and approach to managing state across application UIs, then that’s up for a discussion.

Now that picture starts to look a little focused and communicated.

Each colored section represents a focus point in terms of tech stack. You are able to put blue and green blocks because the red block supports that. And the pink block is supported by the blue block and so on and so forth. In order to swap the pink block, you would need to ensure the jigsaw puzzle is solved between the blue block and the next colored block (orange, for example). And that would also have an impact on the blocks above and so on.

AI-Driven Tech Stacks

All of sudden, as vibe coding platforms emerge, we see a plethora of SaaS and job opportunities all listing these frameworks at the center, right, and left. We see the mention of Replit, Codex, Lovable, etc. as the primary tech stack and then other languages and frameworks emerge. The main reason behind this is that now the primary investment was made to support the development around these vibe platforms.

Is “vibing” a framework, a platform, or something else?

Now, the whole scenario of a project being built with .NET framework, or Next, or MEAN stack app is that you want to communicate the most important aspects of a project. In a .NET application, the most important component is definitely the .NET stack, and you need to have the audience understand that they need to be hands-on with .NET framework and understand different dependencies, lifecycle events, and more. For a MEAN app, you need the developer to be hands on with all–database, UI, and the backend API layer.

With that, I believe the reason the “vibe platform” is communicated is to define strict expectations that the platform is primarily developed using the “vibe platform” and you must have the skills and basic understanding of getting the “vibe platform” to work.

The point is, an application is not just the framework that is being used to write the business-logic, but it contains layers over layers of services and runtimes that make it function. But, those layers and services can be replaced. An IIS web server can be easily replaced with an Apache alternative, or a Redis cache can be swapped for a memcached or an alternative; the swaps would definitely be challenging in their own sense.

When I was working on Distant Ride Fail, I explicitly told him that I would be using Unity and, with this alone, he was informed that the project would use C# as a language, and everything that comes with it.

Conclusion

I believe, the addition of a vibe platform demands that we consider it one of the most important frameworks (if not “the ultimate” most important framework). If you develop your applications using vibe platforms then it makes sense and is only fair that you communicate this to the onboarding engineers and developers.

I have seen several posts and opportunities on LinkedIn or freelance platforms such as Upwork where the founders clear communicate that they expect some skills with AI-driven or vibe platforms. And that is a great thing–even though I am personally not a viber. And that gives me an idea that I must avoid these projects as “thar be dragons”.