CRM implementation and AI creation of docs

While continuing my work on implementing our first customer, I started thinking about how I could better explain the implementation process of GrowERP to you. That's when I discovered a very useful feature of AI: the ability to generate detailed documentation from any part of the system code... more on that later.

This week, the upload/download feature for user and company information was completed. Since company and user were among the first features implemented in the system—back when my Flutter experience was still limited—I couldn’t resist doing some refactoring, especially since error handling and screen messages clearly needed improvement.

However, this isn’t always a good practice. Refactoring often leads to more refactoring, and the job can become endless. In this case, the login/logout screens had similar issues. Without automated tests, it would be nearly impossible to complete such tasks with confidence.

Fortunately, automated tests saved the day by allowing me to quickly verify that the system still worked after refactoring.

During the process, I discovered that the web session was being remembered incorrectly, so I replaced the Hive database with the shared_preferences package. Since only limited data—mainly the API key—needs to be persisted, this package fits the bill.

Still, some tests now need fixing... it's always ongoing. I’ll try resolving them with AI assistance and let you know how it goes.

I’m using AI more and more in coding, treating it as a coding partner. In the past, I worked with various programmers, and I have to admit—AI behaves quite similarly. You can ask it to code, stop it, provide more direction, and continue as needed.

Returning to the topic of documentation, I started with this prompt:

"Document the leads download process from frontend to backend. When there are file references, make the name link to the GitHub growerp/growerp repository using the master branch."

The AI delivered decent results by locating relevant code across the frontend and backend. I then extended the request to include GitHub links for easy code access. You can find the results in our GitHub repository.

Below is the current implementation plan. Please join the effort by providing your suggestions and comments.

If you found this article valuable, don’t keep it to yourself—spread the word! Share it with your friends, family, and colleagues to inspire more people to build business applications!

If you've been forwarded this email, subscribe here.

Thanks for reading. Any comments? Send them to support@growerp.com.

After analyzing the results in NotebookLM, we identified the following key focus areas:

1. Sales & Lead Management Workflows

2. Customer Service & Relationship Management Workflows

3. General Customer Data Management

4. Reporting & Analytics

In this article, let’s focus on the first area: Sales & Lead Management Workflows.

This area includes four key components: lead generation, qualification and nurturing, opportunity management, and deal closing. Let’s break them down.

This workflow is triggered by a new inquiry—whether via a website form, email, phone call, social media message, referral, or a lead generated from LinkedIn. LinkedIn leads are still generated externally. Only qualified leads (those who have responded to email sequences and shown potential interest) are uploaded into the system.

This begins when a qualified lead is created, usually along with an event capturing additional information such as the lead’s function and interests.

If the lead qualifies further, the sales rep creates an associated opportunity. If not, the lead is marked as disqualified and archived, though they’ll still be included in standard mailing lists.

This workflow is triggered when a lead becomes an opportunity. The lead enters a nurturing email sequence. If no interest is shown, the opportunity is closed and the lead is disqualified.

If there is a positive response, the opportunity's progress is tracked using defined stages, which are reflected in the dashboard.

Proposals may be sent to the lead as part of this process, linked to the opportunity and treated as an order in a specific status.

This starts when an opportunity is marked as “Closed Won.” If a proposal exists, it becomes an approved order and kicks off the onboarding or delivery process—depending on your specific business.

At this stage, the lead is promoted to a customer, completing this workflow.

1. Enable uploading of new leads.

2. Add web URLs to person and company records.

3. Show all opportunities in a single list, across all employees (suitable for small businesses).

4. Add events to the system. The existing task model can be extended with a new type: event. Tasks already support linking to various models.