Redmith

In my previous blogs, I wrote about operations development and employee engagement. Both were major parts of the company that needed attention after I started taking over more responsibility.

Operations were the first major challenge. Most of the work was manual, dependent on books, memory, phone calls, and scattered communication. Slowly, I started moving the company into a more structured system by using digital logs, improving billing, tracking POD, handling payment logs, and connecting some parts of communication through automation. This helped reduce manual errors and made the daily work more trackable.

Employee engagement was another major learning curve. I had to understand how to communicate with employees, train them, handle language barriers, and also learn from hiring mistakes. Over time, I understood that systems alone are not enough. People need to understand those systems, and the systems themselves need to be simple enough for the team to actually use.

Now, after one year of changing a major part of operations and learning how people work within those systems, I feel I can start thinking about the next stage.

The next stage is not immediately about building something very large. Before building an app for the logistics company, I first want to understand how app building works in a practical way. I do not want to directly start with a complex business app without learning the process properly. So, I decided to take up a smaller internal project: a rental property management app.

This rental app is mainly for internal family use, but for me it is also a test project to learn Flutter and understand app development more clearly. The idea is to build a simple app where property owners can log in, add rental properties, add tenants, assign tenants to properties, track rent payments, update maintenance issues, upload files, and get reminders.

The app will be built using Flutter because I want to learn cross-platform development. For backend storage, I am planning to use Firebase, as it can help manage users, data, documents, and updates. Since this is a small internal app, it does not need to begin with too many users. A few user logins should be enough for the first version.

The purpose of the app is simple: reduce manual tracking.

Rental management can become scattered when details are stored in notebooks, messages, memory, or separate files. The app should bring the basic information into one place. It should answer simple questions quickly: which properties are active, who is staying where, what rent is pending, what has been paid, what maintenance issue needs attention, and whether any documents or updates are required.

The first step was to understand the app’s purpose and target users. The target users are property owners who need a simple way to manage rental details. Since this is not a public app, the design does not need to solve every rental problem in the market. It only needs to solve the actual problems of the users who will use it.

After that, I started working on the Information Architecture.

At a beginner level, I understood IA as the process of deciding what information exists inside the app and where it belongs. For this rental app, the main sections are Properties, Tenants, Payments, Documents, Maintenance, and Reminders.

Properties will store details such as property type, flat or unit details, area, photos, amenities, documents, tax-related files, and other property information. Tenants will store details such as contact information, ID proof, alternate contacts, work proof, assigned property, rent due date, and rental agreement. Payments will track rent status, pending amounts, paid amounts, file uploads, and payment updates. Maintenance will track repairs, contacts, amounts, and who the payment is payable to.

The important part was understanding that the app is not just a list of properties or tenants. The real value comes when these records are connected. A property should show which tenant is assigned to it. A tenant should show which property they are staying in. Rent should be connected to both the property and the tenant. Documents and reminders should support this structure.

Once the basic structure was clear, I moved to user flow.

The user flow starts with a simple login or signup process using a mobile number, name, and a family sharing code. Since this is an internal app, access should be limited and controlled. After login, the user reaches the home page.

The home page should act like a dashboard or heads-up display. It should show the current month, total rent, pending rent, and a list of tenants or properties that need attention. From the home page, the user should be able to check payment status, update rent, upload payment proof, and move into property or tenant details.

The bottom navigation can keep the app simple, with sections such as Home, Properties, Tenants, and User Account. The Properties section will allow users to add a new property, fill in details, view the property list, select a property, check documents, view rent amount, track maintenance, and see tenant history. The Tenants section will allow users to add tenants, fill in details, assign them to properties, upload ID proof, add alternate contact details, set rent due dates, and generate or view rental agreements.

After this, I started early low-fidelity wireframing.

The wireframes were mostly focused on the home page because that is where the user should get the most important overview. I explored different layouts for showing total rent, pending rent, month filters, pending lists, tenant tables, status indicators, and bottom navigation. At this stage, the goal was not to make the design look good. The goal was to understand where information should sit and what the user should see first.

From the wireframe brainstorming, the home page became clearer. It should first show the total situation, then what needs attention, then the list of tenants or payments, and then give navigation options. This makes the app useful from the first screen itself.

This project is still in the early stage. I have only started with purpose, target users, Information Architecture, user flow, and early wireframes. But even this process has helped me understand app development better than just watching tutorials or jumping directly into coding.

For me, this rental app is not just about managing rental properties. It is a learning project. It is a way to understand how to think before building. What is the purpose? Who is the user? What information is needed? How does the user move through the app? What should be shown first? What should be stored? What can wait for later?

These are the same questions I will eventually need to ask before building any larger app for the logistics business.

Language barrier

Having to talk to employees from the perspective of an employer is different. I myself had no experience being a full-time employee, with just two internships totaling six months of working and learning with companies. I had a tough start figuring out how to handle and talk to employees. My experience was in gaming and film companies, with very different people around me. But this field was different and vastly unknown.

I faced language barrier problems, miscommunication, not understanding slang or intent, and many more challenges. I could only become better by spending more time with the team—talking to them and trying to understand them. I am still learning to adapt to them and their terminology, not just logistics but also the local use of language.

I can speak Hindi, which is a common tongue, but not numbers, dates, or days fluently. I am very much used to speaking in English and had never needed to speak in raw, local Hindi. It took me a while, but I caught up with daily conversations. I still struggle with certain dialects and slang.

But this was just the starting barrier. The fact that I did not have any experience in employee engagement was the biggest problem. This would not be solved just by spending time; I had to learn from forums and books. So, I started reading books on MBA and related topics, understanding and learning about biases, which helped me a lot. This also helped me teach them the tools and systems that I mentioned in my previous blog.

Employee reliability

There is always a trust factor where we can only rely on employees to a certain point. So, building automated tools and reducing manual error solved a lot of this, but it was never completely finished. Many tools were built to minimize friction in work and make it easy to take and place orders, which worked well.

Next, we decided to hire a person for marketing and sales. With no experience in this segment, I made some of the worst decisions I could have made. We hired up to four different employees who walked in for job opportunities, with no experience or knowledge in logistics or marketing. This was a huge problem. I expected them to do their job just by hiring them, which was wrong, and I learned a lot from it.

Then I started narrowing down potential clients to reach out to, but that also did not go well. The people I hired were not prepared and did not have even a basic idea of how to approach clients. I gave them a list of tasks and even a script to talk, but there was no success.

This helped me conclude that I did a poor job of hiring. They were simply not suitable for the role. They could have been better used for office operations such as data entry and office support duties, which they often did on their own without being asked. It was unfortunate to hire and then let them go when it did not work out.

The problems with this hiring process were: no clear directives, weak filtering in the interview process, not looking for experience, offering internships or training without clarity or interest, and ultimately hiring employees who became a drag on both the company and themselves.

What could I have done better? / Questions to ask myself

Learn how to hire and understand the purpose of hiring. When is the right time to hire someone? Do we really need a new employee? Understand cause and effect, and avoid hiring just for the sake of it.

Experience gained

Even though I hired incorrectly, I believe it helped me understand who exactly to hire and what to look for. I learned how much of a role I can play in shaping the daily work of an employee, and how useful that is for both the company and the employee. I also understood how important it is to clearly differentiate roles.

I started learning again from multiple forums and books on employment. One of the best I have read so far is The Hard Thing About Hard Things. I also learned when to hire, which I believe is a key factor. What I mean by “when to hire” is that I should only hire when the company truly needs a specific set of operations that requires a dedicated person or department.

Only when there is a clear opportunity and a strong need for better operations should hiring happen—role-specific and preferably someone with experience. I can see this becoming necessary when we increase order volume. To do that, we need to focus on receiving a higher number of orders daily.

My next blog will be on order volume and consistency in order placement.

Operations and employee engagement are still a struggle. But I can see I have come a long way from where I was and still see plenty of potential. The fact that I spent so much time on these two segments would be quite rhetorical to most, but bad operational management and staff were killing the growth of the company.

Set 1: Operations status quo upon arrival

As unexpected as I was with my role in logistics, and the family legacy being such, the only difference was that it was at a stage where I could do anything. That was a time when I had the will and energy to take on any challenge, which I still do, but now with a pace and more realistic steps toward progress.

To begin with, our company operations were all manual logs in books. There were too many uncertainties with this method. Just to name a few: handwritten errors, general laziness, and manual labor for tracking back. There was a high volume of orders and practically no trackback even for data storage and employee reliability. It was a rabbit hole of flaws and uncertainty. Simply implementing new systems and introducing a computer would have been a nightmare for employees to learn. Data logging needed to be productive but also designed in a way that made sense for employees who had learned to use WhatsApp and UPI apps for survival, with practically no formal schooling.

Stage 1 – Making sense and budget

So, I had to pick a tool that could log data efficiently and a layout that could be taught and trained easily. Also, it had to be a tool that wouldn’t cost much or anything, so we could stay professional and create a robust system. This was the operational side.

However, my employees had no exposure to computers and had only adapted to cell phones because the world pushed them to. I still wonder how the business survived as long as it did before I took over. To get to the point, I had to train them while also building a system that worked for our company.

What I noticed early on in the team was that they were extremely hardworking. Doing this work daily, just relying on memory and paper data, was an impressive skill. All I had to do was find a way to transfer those skills into a system that would make operations easier.

I started by exploring existing software from many vendors and shortlisted them. However, all the systems were built around the companies that made them, not in an ideal operational manner—at least not how I wanted them. Don’t get me wrong, they did a great job building them, but it was simply not workable for my team.

So, after a lot of trial and error, I chose the most basic form of data logging that has been improved for decades: “Sheets.” I went with Google Sheets because of its advantages, such as cloud operations, data structure, Apps Script for automation, connectivity, and workspace add-ons. This gave me a way to build an ERP myself—not from scratch, but by using multiple tools and connecting them to act as one system.

This was a kickstart and instantly improved results. It barely took our team a week to learn how to click and enter data. I had expected at least a month. In the initial days, I did the entries, and later the staff caught up.

With data entry and daily logs on track, I gradually made the UI clearer and divided operations into two segments: internal and external. Internal was for the self-owned fleet, and external was for hired and associated vehicles. It was remarkable how much data was collected in just a few months—data on different vehicles, contacts, route frequency, timing, the most profitable vehicle types, and more.

As our team started getting used to the new workflow, more flaws and loopholes appeared that I had to fix. One such issue was bills and payment receipts. For the first month after I joined, we were still writing bills on paper, taking pictures, and sending them. This was unprofessional and messy. So, we created a digital version of these bills. We got an instant positive response, and many clients who were impressed started giving more orders, increasing frequency.

Then my team had a human error problem, such as entering names incorrectly and manually typing details for bills. This required a solution. We pre-built entries for clients and carriers and used dropdown selections. This made things much faster and easier. With the help of Apps Script, we automated trip entry to billing with just one click. Now we can export bulk bills instantly.

At this point, we had a automated daily log and an billing system. Up next was tracking POD (Proof of Delivery) and payment logs. Building this didn’t take much time, as we already had the data—we just had to connect it. By doing so, we separated POD by linking it to the main operations sheets and created a separate POD log entry where my team could track payments and proofs. This made receiving and reminders much simpler.

Next, we needed a way to send bills and trip confirmations to clients and carriers. This would build trust and reliability. After researching options, I came across Twilio—a business solution for automating messages in bulk. This helped us send WhatsApp bills to clients and carriers without errors. This again became a revolution. Everyone who received the bills and trip confirmations reached back, asking how we did it.

All this happened within a year, with a lot more to come. I have more plans to improve operations, but I will have to put them on hold. For now, I need to concentrate on improving order volume. The number of orders I take has increased, but not the volume. This needs to improve significantly.

Last update was on the blog was arnound 7 Moths on 3 years on Tumblr.

Before that, I had updated about the Babu app, a very ambitious project which was, I would say, inspired by UI/UX design exploration. But by far that was a very instructive course and by far the very optimistic one.

Bubu app's base work on understanding the user and building a wireframe prototype went well, but I haven't grasped how the business operates entirely in practical terms at this early stage. The goal of the app remains the same, but with a lot of minute changes that would make a whole lot of difference. After a year on field operations, I had to put hold on the app dev and concentrate on operations. My days started getting more involved in operations, improving the baseline, and getting stability. To be frank, 60% of my work this year has been improving operations and dealing with employees and 20% on getting new orders and 10% on new projects and so on.

In the next blog, I will mention my updates on Operations dev and employee engagement.

1. Figma Layout – From Sketch to Screen

The design process began with translating initial hand-drawn sketches into structured, digital templates on Figma. This early stage focused on maintaining the original concept’s intent while creating a more organised and scalable visual structure. Seeing ideas take shape on-screen in a linear, navigable format was a key milestone in the project’s progression.

2. Home Screen – Simple, Intuitive Navigation

The home screen was designed with clarity and usability as top priorities. The layout features a header and footer for quick access to key app functions, enabling users to reach any feature in just a few taps.

Dynamic access points ensure the user can locate information from multiple starting points.

Clean visual hierarchy keeps focus on essential details without clutter.

Consistent iconography supports intuitive, text-free navigation when needed.

3. User Profile – Personalization & Data Access

The user profile page presents a clean, accessible summary of personal and trip-related information.

Displays user identity and verification status prominently.

Lists trip history in a well-organized format.

Allows full truck information management (add, edit, delete).

4. Truck Details – Guided Interaction

The truck details section offers a streamlined way to view and update vehicle information.

Truck type, weight, and configuration are clearly presented.

Integrated pop-up support menu offers quick access to help, navigation shortcuts, and essential actions—preventing the user from feeling “stuck” at any point.

5. Design Consistency – Visual Cues as a Language

A consistent set of icons and UI patterns has been applied across the app, allowing users to rely on visual recognition rather than memorizing labels. This strengthens usability, particularly for new users or those in fast-paced environments.

Paper Prototyping is a fun stage, as I get to sketch, iterate multiple layouts and designs and brainstorm ideas for the UI. What's, and I love the "idea of crazy 8". It's quick, fun and intuitive.

Rules for crazy 8 are simple: sketch possible UI ideas by making 8 illustrations within 8 minutes in 8 boxes. The paper is divided into 8 segments, each of which is an individual screen with one minute for each box.

This seems competitive, but it's not a test; it's a way to put out ideas on paper and push our limits. The rules are simple, but I could never complete on time, as I kept drafting idea after idea, and it works for me that way. Haha!

The next stage was to pick ideas in parts from the 8 sketches that are ideal and work best. Then draft a unified single layout that works best.

After the primary illustration, I made another scroll-down version for he homepage in the elongated sketch. This will be my pilot page, and the rest are transition pages.

As I didn't want to overly complicate, I kept the page count to 3. The home page is the pilot page, and account and vehicle details are transition pages. The secondary page will hold data such as the user's profile, documents and vehicle data.

To break down further and understand how the app is going to be structured, I drafted a quick breakdown of Information that we will later translate into the app. The target is to make myself aware of possible options, user flow with page breakdown and information with consistency. I broke the information into 2 IA- One for the basic layout with home page and further navigation, and the possible features.

The first illustration is a breakdown of Login/New user, Homepage, Account details, and Vehicle Details. These three will be the guiding sections and will be further broken down.

My entire idea for the app is to be simple so that anyone with minimal to no knowledge of a smartphone can handle the app. Yet, the user flow seems too dynamic and complicated at first glance. So, I thought I would just summarise all the information first and then refine and fine-tune it later.

I had to further write/draft information, but the paper size was restrictive with less space, and I had to draft on a new paper.

It's an extension of the first draft.

Homepage, is further divided in to Driver preferences, Account Details, Vehicle Details.

So the navigation goes ( After downloading the app)

The user is given an option to either log in or register for the app. Registration is as simple as logging in; you just need a registered phone number. If the user is registering, they need a registered mobile number and an ID (driver's license number/photo). Verification for the ID is done later, but the user is navigated to the homepage and is ready for further steps.

Once the user is in, he is given options to put his preferences, such as the Type of vehicle and route that he prefers. He gets a token number and verification of confirmation. That's all—the user is on the list! The driver can be an existing or new user, but it's still the same amount of friction and time taken to get to the listing.

Once there is a match for the driver's preference, he gets a notification request for an order. Once the driver agrees, he gets a detailed breakdown of freight charges and the exact location for pickup. After confirming he the details are shared with the consignee and consignor. WIF, the driver rejects the request? Then the order will be processed to the next waiting person on the list as per the token. This will assure the driver about a strong system in place and guaranteed orders with low commission rates.

On confirming, the driver can either complete his registration with a Driver's licence and vehicle RC or provide his phone numbers. Until the point of order confirmation, both registered and new users only need their phone numbers; the rest can be provided once the order is confirmed.

The homepage is going to be the pilot of the app, which displays driver preferences along side current trip status.

Other key Pages would be Account details and Vehicle Details, which are data stored for the user and vehicle, such as past trips and general info.

Understanding why the user needs the app and its applicability in terms of a story is a kickstart for the prototyping stage, as it helps me understand the user's perspective by simulating a fictional real-world scenario. I will be making two storyboards. Big Picture and Close-up storyboards.

Big picture (BP) In BP, the user's pain points are mentioned, and he is told how he can discover the "Babbu" app to solve the problem by promoting the driver in an easy and convenient way.

The driver is upset, unable to find a load and stuck at the parking paying bills.

The driver is confused about the new technology on the phone and misses the simpler times

A fellow driver is excited about an app and shares it with him

The app is "Babbu", which is built for drivers to find loads.

Ui of the new app is simple and available in a language he can read and understand. Driver logs in and puts his details and preferences in minutes/with minimal login details, and he is on the list for orders

The driver quickly gets a notification that he has a trip and is on the way with a load, and is happy. He remembers the simpler times again.

confirmationClose picture (CP)

CP is the closer understanding of how the user gets from point to point. It's the in-between and usually the technicalities of user behaviour, problems, and how they are solved.

Apps built in modern times concentrate on specific users and use complicated terminology that's hard for drivers to understand.

The "Babbu" app is a simple, yet straightforward app built for drivers with a preferred choice of language.

The app has an easy onboarding process with just a phone number and driver's license.

Then the driver chooses his vehicle type from the drop-down and preferred route.

Within minutes driver is listed for availability and gets a token.

The driver gets an option to accept/decline a trip, and the trip is confirmed upon the driver's approval.

Reflection -

With the storyboard, little by little I am able to relate ith users and understand how it can work and why users would use my app.

I cannot afford to do an extensive survey or talk to drivers on a wide scale. So, this process is helping out in shaping what "Babbbu" can be.

I can see how easy friction can build up for a user who has a pain point and how they can opt out. That puts us in a position to ease the process further after understanding the friction.

Users can easily get distracted or might feel this is another mysterious technology if there are many barriers. So, keeping the technicalities minimal is the key, and once we get the user on board and are satisfied with an order, then they will be willing to further provide information if required.

The priority of the app is the users who are drivers; solving the problem/pain point they have is the key solution the app provides.

Finally caught up with Prototyping.

What does the product do?

The product helps D2 drivers promote themselves, without having to learn new technology or hunt for the next load. It provides consistency and convenience.

Why should the user care?

User struggles to find loads for their truck and are constantly on the search for the next job. The next job can come from anywhere and isn't consistent; sometimes it might take up to a week or even a month. By solving this problem, users will be relieved and concentrate on just the job. with consistent trips.

Khushiyal Singh is a middle-aged driver. His main goal is to provide for his family by driving (D2). Khushiyal struggles to find a job and feels that he is unable to keep up with the growing technology and world. He wants a trusting, consistent and reliable source for loads. Khushiyal is not well educated with technology, but over the years he has learnt to handle a phone, Google Maps and manage payments online with UPI. He uses a Hindi language font to convert text and manage his trips, and communicate with owners.

"AS a truck driver, I want to get a consistent/reliable source of loads, so that I can make a living and provide for my family "

Identifying and understanding users.

To start of, I will put in my observation from my short exp that is of 2 months.

I will be dividing my observation into 4 stages.

Existing Force

Daily life

Working conditions

Future?

Final note

Existing force

India has a working force of huge labour force. It's obvious that with such a huge population, there is only a little that a country can share as resources. A similar country is China.

The labour force is divided in to multiple sectors from getting a job done and requiring a lot of man force. To summarise, all the jab's that require an output with repetition and minimal to no skillset's requirement that can be done by most people fall under this category. It can vary from huge force working at call centers or jobs of factory workers and drivers or even stormtroopers working for the empire.

Further, there are multiple divisions in driver sectors as well. Let's assume we are concentrating on the driver segment and dividing drivers into 2 categories for easy breakdown and understandability.

One, consumer-based and the other is supply-based. consumer-based can be personal drivers, drivers at valet parking, school/pubic transportation. I hope you get the point.

The second category would be supply-based. This sector of drivers that transport goods/cargo, materials that range from raw to consumer goods, products and everything that's materialised and transported in bulk. This also includes short-haul goods such as moving furniture or household cargo.

Let, dive deep into the drivers segment of the force.

(idea for this blog is priority on Supply based drivers, lets say these driver are D2)

2.Daily life

The daily life of D2 can vary drastically from an employed driver to a freelance driver. But, marginally, all work done is always the same, and only the liability is different in terms of payment and trust. D2 drivers can be owners of their own vehicle or drive a provided vehicle by an owner. Regardless, most of them are still freelance drivers. I will explain the difference in a bit.

The day starts with a cup of tea and a call from a broker/contractor or owner. AS most D2 get an estimate idea of location and type of material that needs to be picked up. Further, upon order confirmation and driver availability, D2 get the loading location (point where material/cargo needs to be picked) Usually, drivers are on standby at parking locations paid/owned by the owners. Upon order confirmation, they leave to the provided location for pickup and wait till the material is loaded, and the rest is simple: they get the goods loaded and head to the provided destination. There is a whole lot that happens between the delivery and at the loading/unloading point, and after the delivery. (For the point of context, I will explain the details in a later blog)

3. Working Conditions

Working conditions have drastically changed in the past decades. What seems like a golden investment in owning and driving self vehicle seems out of reach with the ongoing complications and new technology that drivers are not able to keep up with. Also, ever-changing state rules and new company policies make it even harder. Before, drivers and freight deliveries were much different,a nd the marginal profits stayed and made a huge change. Now, even after a decade, the driver pay remains the same, and with a growing economy and technology, it's hard to keep up with daily needs.

Only few of many drivers have a stable Job and a reliable source of income, but that's not guaranteed for the long term. Drivers are used to being in conditions where they have to leave home for 6 months or sometimes a couple of years. Living can get tough if one's job isn't secured and they own a truck that dint receive any orders for a while. As this D2 is responsible for maintaining his vehicle expenses and himself.

On the bright side, if a self-owned D2 gets shipment with less than a day or two in waiting can still make a living. Assume a D2 driving route with his permutations is from Hyderabad - Mumbai and back. To make one way trip it takes him about 2 days, and a round trip takes 4 if they get back-to-back confirmed orders. SO, let's assume a driver gets orders every time he ends a trip. D2 will be making two round trips a week and eight trips a month. Okay, that seems pretty good, what if i say from my 2 months of observation,n i got to speak to about 10-15 drivers who have been driving for over 10-15 years, and highest number of trips done were 5. which is when the market and economy was at its best.

Even though my observation and sample group are very short for any review, I sense a lack of interest for driver preference by the higher ups.

4. Future

The future for logistics and development in India seems to be progressing. Huge developments are going to happen. What about the labour force that is the backbone and heavy lifting unit? Would D2 imagine their children working as a driver? Why was there a time when many wanted to work as a driver and invested and thrived, and now they don't see a next generation in driving? Well, ik how I sound. Let's take a different perspective. Imagine your kid completes schooling, higher studies and graduates as an engineer just like the other 100,00000. Now, when he is just as accomplished as the other whatever number, what are the possible jobs one can get into? What is the educated employment rate today? 8.25% My friends who have civil, mechanical, aeronautical, and software engineering degrees are about 30. I cannot count a single one of them in a field that is closer to what they have graduated in. Okay, a lot of Bla bla.

ahm. ahm. My point is, today's graduates aren't any different from the early ages of the labour force that's diminishing today. The drivers I spoke off earn about 50,000 a month and more when the market is at its peak. My civil engineering friend earns about 35,000. Yeah, the drivers have been driving for over 15 years, but they never had a market that was built for them. Helped them see the future and the benefits that support them.

My final note

Hahah, that was super intense. I don't think I am even gonna read this after years, nor do I expect anyone to. So, what if we start prioritising for a huge sector of workers who need recognition? Well, if with enough time and resources, I believe we someday can see hope and appreciation for every job that has opportunity and freedom when it's not overpopulated and nurtured well. It seems like I sound very optimistic, but I still wanna try.

The road map seems both daunting and intimidating. I love to plan an order and its usual disorder (entropy). As good as it sounds, it never worked out for me to date and time my workflow because, I suck at it. I mostly work when my mood strikes, and I do. I love a plan, but not in an order that's boring, but in a way that I keep pushing when I want to and relax when I have to.

This road map is based on my knowledge of building an app without any prior exp. So, I am gonna start with the basics of UI/UX and go with the wim and learn skills, or outsource what I need.

To start off, 'Design thinking framework'

Empathiuse define IDeiate Prototype test.

le, go!

ERP stands for Enterprise Resource Planning. The idea for this was to build an ERP software that can handle logistics operations on a daily basis. Such as order entry and driver/vehicle assigning, payment for both clients, and expenses for the shipment. Until a month ago, all the operations were manual, paper-based. This process was efficient for taking and billing orders, but tracking payment update and data location and tracking back was a major issue, as it would take a long time. It would often require memorizing all the trips and balance payments, which was not really possible.

For starters, I converted the data entry into digital with naming and dividing work across clients and needs. Now, we have internal, external, and client-based data that is easy to pull out and trace back. For this, I started using Google Sheets and Workspace as my key software. Tracking payment trips and driver details has become much easier and especially checking for pending payments and balance amounts from clients and updating the courier process. To keep it linear and professional, I got a domain for clients that need an online presence and to store data under that domain.

Well, its been over a month now and everything seems to be working fine. But, i can see a future where its gonna add up as we increase the amount of orders, and this process will get complicated. that's a reason i was looking for an ERP software.

I began researching how likely it is that I can build software that fits my needs. Being a positive oddball, I had the confidence that I could build software without any coding knowledge by learning everything and then building software on my own. It would work if I spent my entire time every day working on building one. Irony is that I no longer have such time on hand, and I need to be quick, knowledgeable, and efficient for the sake of business. I started looking for service providers that either have build similar resources or can build one according to my needs.