Forem: Savy

The Art of Value Delivery

Savy — Fri, 09 May 2025 17:33:49 +0000

Ever wonder what sets successful software products apart from the rest? It’s not just about writing clean code or having the latest features. It’s about "delivering value". Real, tangible value.
As a developer who's worked across dynamic e-commerce platforms I can tell you,it’s this understanding of value that ultimately determines whether a product thrives or fades away.
It’s what separates products that vanish from those that grow sustainably. This guide offers a practical look into delivering value effectively, especially in the software world.

1. What is Value?

In business, value is the actual benefit a user or customer gets in exchange for time, money, or attention. It’s not about features. It’s about outcomes: saving time, making money, or feeling secure. When you build a product, you’re not just writing code, you’re solving someone’s real problem.

2. Types of Value

Here’s how value shows up in real-world use:

Functional Value: Helping someone do something faster or easier.
Economic Value: Saving money or increasing ROI.
Experiential Value: Creating delight or seamless experiences.
Social Value: Building trust, status, or community
Ethical/Sustainable Value: Aligning with environmental or social goals.

Knowing which one you’re delivering shapes everything—from code to customer support.

3. Define Value for Different Audiences

Different users care about different things. A finance team wants ROI. A solo entrepreneur wants speed. Your job is to find the overlap. Start with a core value, then layer in tailored benefits for each group. Keep the language benefit-driven, not feature-heavy.

4. How to Identify What Your Market Values

Use both:

Qualitative signals: User interviews, session recordings, support tickets.
Quantitative data: Usage analytics, survey patterns, churn rates.

Track competitors, but don’t just copy them. Understand why they work. Solve what they miss.

5. Discover and Deepen Understanding

Launch fast, learn faster.

Run:

MVPs
Discovery sprints
Pilot programs

Pair these with feedback loops and product analytics. Watch how people use the product, not just what they say.

6. Who to Target First

Start with:

Early adopters who love testing new tools.
High-pain users who are desperate for solutions.
Influencers who can become your internal champions or vocal customers.

These groups give you the best feedback and traction.

7. Channels That Deliver Value Well

In software, the delivery method is part of the value. Prioritize:

Digital delivery: SaaS platforms, mobile apps, browser tools.
Human support: Personalized onboarding, real-time help.
Ecosystem integration: APIs, payment gateways, partner apps.

Make value accessible in the flow of work.

8. Strategies to Optimize Delivery

Use agile development to ship fast and adapt.
Design modular products that serve different needs.
Build a roadmap with your users, not just for them.

Your product will evolve as your understanding deepens.

9. Measure What Matters

Focus on:

ROI and revenue impact
Retention and active usage
Satisfaction (NPS, reviews)

Tie every KPI to your value proposition.

10. Deliver Fast, Deliver Right

Delivering fast doesn’t mean rushing. It means removing blockers:

Empower cross-functional teams.
Automate releases and tests.
Prioritize tasks using impact vs. effort.

Timely value is more valuable.

11. When to Slow Down or Reprioritize

Hit pause when:

Quality suffers.
User trust declines.
The market shifts.

Frequent reviews keep you agile, not reactive.

12. Raise the Quality Bar

Run release retrospectives.

Use continuous integration and real-time monitoring.
Create feedback loops where users help shape improvements.

It’s not about being perfect. it’s about learning quickly.

13. Scaling Delivery

Map current value streams
Segment and customize offerings.
Automate wherever possible.
Create a repeatable process.
Align your whole team on outcomes, not outputs.

With a solid system and shared focus, you can scale both value and trust.

Final Thoughts

If you’re building software. especially in fast-paced spaces like e-commerce and payments. value delivery isn’t optional. It’s your edge. Start with clarity, stay close to your users and never stop adjusting. That’s how real impact happens.

If you're building in this space or exploring value delivery systems, I'd love to connect. My experience spans everything from writing backend code to leading cross-functional teams toward faster, cleaner value pipelines.

Crypto Commerce - Future of E-Commerce?

Savy — Fri, 14 Jun 2024 17:26:33 +0000

Problem

Tax and death are the two things in the world you cannot avoid!
I disagree, both of them could be avoidable! At least the first one. consider you can sell goods to people without paying any non-rational tax.

Also, some countries are controlling people and building walls between different nations. This is unacceptable. You have the right to trade freely and connect with people all over the world whenever you want.

Solution

Crypto currencies could be our solution. despite the nonrefundable nature of most crypto currencies, they could make humans truly free in terms of trading and payment. Human built a form of currency no government can control.

Features

Selling goods/services with cryptocurrency
Managing inventory
Online presence of products
Connecting to different markets
Converting prices to different cryptocurrencies
Payer can use a wide range of cryptocurrencies
Seller can receive their money quickly in their wallet

Challenges

Seller needs to trust the POS mechanism
Payer needs to trust the seller
Settlement must be fast
Seller should guarantee their product
Seller should reward customers who pay via crypto

Advantages

I can say the best advantage of using Crypto Commerce is reducing taxes. Second, most cryptocurrencies have investment potential. Although sellers can receive stablecoins like USDT, receiving crypto such as BTC or ETH could have long-term benefits.

POV: Customers

Why should someone trust sellers who only accept crypto? While fiat gives all the rights to the buyer, crypto gives rights to the receiver. In this case, the seller has a tough time building trust.

I think the best way to create a culture of paying via crypto requires following steps:

Rewarding crypto payers: If we are selling our products via cryptocurrencies to reduce taxes, it's fair to share some of this savings with the buyer. For example, if you sell your product for $100 and typically pay 13% tax ($13), you should sell it for around $93.50 when accepting crypto. This way, both you and the buyer benefit, splitting the savings: $6.50 for you and $6.50 for the buyer who trusted you. A win-win situation.
Start Small: teach your customers that paying via crypto is safe, let them pay via crypto coins. reward them. give them the feeling they are pioneer of new modern era of money and currency. but this experience should be risk-free. start with very cheapest products. repeat this type of experience for your customer.
Provide Guarantee and Alternatives: Offer all legal information to your customers, show them who you are, and maintain a trustworthy site. Join trust-building platforms, release videos, and present yourself on social media. Take all necessary steps to build trust. Start accepting crypto as an alternative payment method with rewards. Offer PayPal or other traditional forms of payment, so customers feel free to choose their preferred payment method. Never force them to choose cryptocurrency.

Scalable E-Commerce Architecture - Part 2: Shopping Cart

Savy — Fri, 16 Feb 2024 20:48:37 +0000

In my previous article, I discussed Authorize.net and the basic architecture of inventory, product management and catalog services.

Through our exploration, we identified that to implement an effective search and filters system, maintaining an updated source of truth for products is essential.

We achieve this by denormalizing product data and managing each component in a different service, ultimately consolidating all parts into a single database known as Catalog.
For instance, when a new quantity is added for the product in the inventory service, the new quantity is sent to the catalog service, enabling us to search and filter products based on their availability.

Now, ley's div into designing and discussing about the shopping cart service. it is necessary before moving to the registering the order phase.

Advanced Shopping Cart Features

This service is responsible for:

1- Contact information (buyer or customer) related to a store
2- Recipient information (address and contact details)
3- Billing information (same as previous)
4- Products with details such as product ID (*optional), quantity, product tax, product coupon as discount, recipient, delivery date, product add-ons and product subtotal with/without discount.
5- Cart level coupon
6- Agent id (if shopping cart is filling by agent on behalf of the customer)
7- Cart totals, customer budget, total tax, total discount, total shipping rates, total shipping discount and finally grand total.
8- Notes regarding order, processing, delivery and products

In point 4, regarding the products, I've marked the product ID as optional, because sometimes we may need to charge a customer without prior knowledge of their specific product preferences. he may just set the delivery time or recipient with the specific budget.
The product details are typically filled in when the customer begins the checkout process.

Architecture

I'm going to describe how we can build our shopping cart service.

Photo link

As illustrated, we have distinct API endpoints for our shopping cart:
1- Get Cart: This endpoint retrieves the last available shopping cart for a customer, agent, or gust. If the cart doesn't exist, it creates a new cart and returns the empty cart with a UUID. We utilize UUIDs to maintain security and statelessness of our service, a common practice in monolithic or stateful projects where sessions are typically used for managing shopping carts for guests.

2- Add Contact: This endpoint sets the buyer's information. While this could be automated in the previous endpoint for customers and guests, it's necessary to allow agents to set the contact for the shopping cart, especially when a customer calls the CRM to register a new order.

3- Add Address: This endpoint can be called by the customer, guest or agent. it sets either the recipient (shipping address) or the billing address (buyer), with or without specific products.

4- Set Product: This endpoint adds a product to the cart. the product details may be empty initially, but the delivery date and delivery zip code should be provided. Subsequently, another service calculates the cart totals.

5- Set Cart Coupon: As you may have noticed, we had different types of discounts and coupons. For example, a total discount on the cart or shipping discount.

6- Set Shipping: When adding a product, it's possible to set the shipping method later. so we add this endpoint to update the shipping method for specific cart product(s).

7- Calculating the Cart Totals: This service acts as a Saga handler. it validates the products in the cart and calculates the final cart totals. This process, being the most complex part of the shopping cart service.

Saga Challenges

When utilizing message broker and saga handler, designing a stateful engine is important. Steps should be executed in specific order to prevent any errors.
Therefore, we have to set different statuses for the cart and lock it based on that status. the final status is CALCULATED.

Sync and Async challenge

When a customer adds a new product to the shopping cart, a long process begins to validate and calculate the cart totals.
This may take less than a few seconds if everything works well.

The first question is this: Should we return the calculated cart every time a customer adds a product to their cart?

Solutions

1- Wait for Calculation: The initial approach involves waiting for the calculation process to complete before returning the processed cart data as an API response to the frontend.
This approach may seem ideal, especially for smaller applications or monolithic architectures. It's a best practice used in most e-commerce applications like Bagisto. Additionally, setting a timeout on the frontend can help manage instances where the process takes longer or fails.

2- Return 'OK' Message: The second solution could be returning an 'OK' message to the front immediately. The process of updating the cart is running in the background until the frontend sends another request and fetches the latest status of the cart.
This approach allows for a near-real-time experience, typically under 5 seconds. During this time, the frontend shows and calculates cart totals itself. A small loading could be added under the cart to indicate that the final status of the cart is not confirmed by the server, but it will likely be confirmed soon.
Since This is the shopping cart stage and not the checkout, we can handle this stage asynchronously.
However, when we proceed to the checkout pages, we have to wait for the final calculation and validation results before registering the order.

The downside of this approach might be showing invalid cart items on the frontend, as the frontend is responsible for calculating the cart totals based on previous data. For most businesses, this error in negligible. However, for some other businesses, it might be impossible due to a lack of data in the frontend.
For example, the frontend might not have access to shipping calculation formula. Additionally, this approach requires a lot of work on the frontend. The frontend needs to use the same calculation formula, which involves extra work and may not be worth it.

3- Implement Event-driven Communication: The third option involves implementing SocketIO to send cart events from backend to the frontend once the processing is complete.
This combines elements of previous solutions, with the frontend receiving an 'OK' message upon initiating the request. Subsequently, when the processing is finished, an event is sent to the frontend via WebSocket. While this approach provides real-time updates to the front-end, it requires additional implementation efforts.

Conclusion

Regarding the Sync or Async challenge, I prefer the first option. Nonetheless, it's imperative to calculate and return the latest cart status whenever the front-end requests it. Whether to handle the process synchronously or asynchronously is entirely up to your discretion. You may opt to manage it entirely on the front-end side or delegate it to the back-end while minimizing front-end involvement.

I will continue to explore system design topics, with a particular focus on e-commerce concepts, in future articles.

I'm interested in hearing your perspective. If you have any comments or questions, please don't hesitate to share them. Thank you for taking the time to read!

Scalable E-Commerce Architecture - Part 1: Inventory, Product and Search

Savy — Fri, 02 Feb 2024 21:34:38 +0000

In this article, I delve into crafting a comprehensive e-commerce micro-service architecture.
In my previous post, I discussed the payment service, utilizing Authorize.net, and now it's time to discuss product services.

Starting Point

I begin with the following figure. I put a "Product DB" in the center, customers actions related to "product" on the right, and agent actions on the left side.

High Quality Image

Technologies and Specifications

Environment: LTS Node.js - 20.10
Programming Language: Typescript - Javascript
Database: RDBMS - MySQL 8 - Redis (Ioredis)
Communication Style: REST API - Kafka Message broker (kafkajs)
Backend Framework: Strapi - Koa or NestJS
Frontend Framework: Nuxt or Next (or any other framework with SSR capability)
Service Contract: Swagger
API Test: Postman - Jest

Searching Challenge

In a micro-service architecture, implementing best practices and ensuring data consistency is crucial.
Consider a scenario, where some part of data updated in the inventory service, such as a product being changed and having no quantity. Who is responsible for removing the product from being sold in the storefront?
similarly, when a product price has been changed in the product management service, which part of the system calculates the new price? who delivers the new price to storefront?

when dealing with distributed systems (micro-service here), we have 2 options to ensure data consistency:

Normalization: saving different parts of data in the different services.
Denormalization: saving a copy of data in another service where the data is needed for some process.

In this system, I used the second option. the main reason behind this decision is necessity for "searching and filtering products".
I've been in many e-commerce projects where "searching and filtering" operation became a significant part of the system. so I prefer to divide the system into smaller parts, but each system should update a central database for products.
Although we may have redundancy for product data, we ensure that searching and filtering will be done efficiently.

Catalog Service

the catalog service is responsible for adding event rules; it saves its data in its database and then sends a copy of updated data to the product service which is responsible for providing product data.

The drawback would be redundant data. we have to keep a large database updated. It seems like we have a monolithic database in the middle of a micro-service architecture, but the point here is that this database and product service do not execute any business logic; they only collect data. All the business logic related to the catalog should be implemented in other services.

Filtering Product, Dynamic Prices

If we had only one place to calculate and display the final product price, a base price and catalog prices would be sufficient. For example, on a single product page where we display the specifications of only one product, including:

Showing the price (or regular price / base price)
Calculated price (or final price)
Base discount (or calculated discount)

We can easily save base price and catalog prices (like category price) in a centralized products database. Then, we are able to perform searches easily. In this case, we can use the Strapi search API to filter and search products based on a range of prices.

*But what about dynamic prices? *
when we show different prices based on dynamic parameters like "customer group" policies, where we show different prices to two different groups of users.
I know, it may sounds a little bit rare, I agree. But we have to deal with this challenge. some of the options are:

1- Performing a search without considering price, and then conducting a second search (price search) to remove unrelated data

it is the first option. for example, if a user selects a range of $20 to $30, we can perform a search without considering the price, then calculate the prices, and filter products within the specific range.
This option is only suitable when we have a large number of products with similar prices.
It could also be implemented in the frontend sometimes, although it's not considered best practice.
The biggest problem with this approach is pagination. When we use pagination, we have a limited number of products on each page. It is possible that when we remove unrelated products from a page, no items remain on that page, and the user has to proceed to the next page. if we don't have a large number of products, we can use a single API call to fetch all products and filter them based on price. in this case, I see no problem with this approach. specially for databases with < 1K records.

2- Using price filter as a middleware

in this approach, we do exactly the opposite. consider you have two different search systems. the first one calculates all product prices and finds the products within that specific price range.
then it passes those product IDs to the next system, which filters final products and do the pagination. it receives the IDs of those products as an argument.

the first advantage of this approach is that we can use pagination. because the pagination will be handled by the framework in the final process. unlike the previous approach which was suitable for searching without pagination, this approach is better suited for paginated search systems.

the drawback of this approach is that calculating prices for all products may be expensive for the system.
it could be a significant process load for the system, specially for systems with a large number of products. consider having to process 200K prices and send their IDs to search system for further filtering!

Another problem could be filtering based on IDs. we may have a landing page where only half of the products have dynamic prices; and other products have only base price.
So, we have to process prices for all products, even if the price could be filtered easily by the framework in the data layer using ORM.

Another disadvantage of this approach could be sorting based on product price. since second searching system only received the IDs of products from previous filter, it doesn't have any access to their prices in this step. therefore, we may have to remove sorting based on price in this approach.

this approach could be suitable when dealing with a medium-sized database, something like 1k to 10k products, specially with a variety of price ranges.

3- Calculating and saving different prices into database

The third approach involves doing the homework sooner.
In this approach, when a dynamic price added for a product, we calculate all possible prices based on different rules.
for example, we may have 10 different prices for a single product, based on factors such as:
1- Customer groups
2- Events
3- Stores
4- Zones
5- Discounts
6- ...

The next step would be applying and considering these rules for incoming search request. you have to automatically extract parameters and apply them to search query.

The advantage of this approach is that filtering will be handled on data layer. the filtering would be done at a low-level part of the system.

Also, another benefit would be centralized data. When you have a source of truth for prices in your data layer, you can use various tools to perform searches (Elasticsearch, Algolia, Cache, etc.).

One of the downsides of this approach could be facing inconsistency and dirty reads.
for example, consider a situation where you updated the price of a product, but due to latency or some specific problem, the price didn't get updated, so the old price is showing in the search results until you implement extra strategies.

Another down side would be saving a large number of unused data. for example you may calculate 20 different prices for a single product, which might not be used in any search.
what will happen to those prices?
when you may have lots of products, it gets worse.

This approach guarantees a fast search and provides a source of truth for a wide range of search systems. however, you should consider the cost of saving a huge amount of unused data.

this approach will work for any number of products, and I can consider it the best practice, as it also enables sorting by price option.

the only the challenge that may arise is when some dynamic prices won't be processed until specific requirements are met.
for example, a product may have a specific price based on another external API, or the product price may be extremely sensitive to user input (e.g., weight of gold or a mix of some materials).
I think for those scenarios, it's always better not to provide batch filtering for price.

Tools and 3rd parties

In order to build and scale the system fast and reliably, we use some tools and outsource some functionalities:

Payment: Authorize.net - PayPal
Fast Search: Algolia
Inventory Management: Zoho Inventory
CRM: Zoho CRM
Chat and Support: SaleIQ or any other online chat provider
Recommendation: MoEngage
Analytics: Google Analytics
Tag Management: Google GTM

Using these tools isn't mandatory, but they are very helpful for specific tasks, specially if you don't have a large budget and a big team. for small teams (2-5 developers), it's always better to consider using reliable 3rd parties.

Conclusion

Selecting the optimal approach for dynamic pricing in e-commerce micro-service architectures is vital for performance. Consider factors like scalability and data consistency. Share your thoughts and experiences on dynamic pricing in the comments below - your feedback is valuable!

Developer's Guide to Authorize.net Payment Integration: PCI Compliance, Workflows, and Interactive Demos

Savy — Tue, 03 Oct 2023 14:03:29 +0000

Part 1 of e-commerce journey: Decide for payment gateway

Audiences

This article consists of 2 parts and is specifically beneficial for only two groups of audiences.

1- Businesses Owners: This article would be valuable for business owners interested exploring and implementing a simplified approach to a payment gateway, particularly for businesses in North America and Canada.
2- Fellow Tech Enthusiasts like Me: In this article, I've happily shared some of my experiences with testing payment gateways.

Introduction

ove the past few weeks, I've been on the hunt for a solution to replace the payment gateway of a commerce site. I had two key objectives:

1- The solution shouldn't necessitate complex PCI-DSS (the legal aspect)
2- The design and user experience of the payment process are crucial (UX).

My Experience as Developer

When you first venture into the realm of documentation, you'll encounter numerous concepts and terms which might leave you feeling a bit bewildered. most of the time you find yourself juggling three distinctive facets of payment gateway simultaneously, striving to strike a harmonious balance among them:

1- The Technical Aspect: Security, UI and API, often takes the forefront.
2- The Legal Aspect: PCI-DSSs I mean! 😩
3- The Logical and Business-related Aspect: factors like time constraints and complexity, also plays a pivotal role in the equation.

First Step: Boring PCI Compliance!

There are 7 (or more probably) different levels of PCI DSSs. If you want to know more about PCI DSSs click here

For small businesses that prefer not to invest a lot of time in security and legal procedures and don't require a complex payment method (which may requires storing customer card data)there are two preferable options:

1- PCI DSS QAS A (I refer to this as Level A): The simplest one, you can't touch the sensitive card data (such as card numbers and expiration dates), even if you want 😅. This option includes redirect (HPP), iframe (HPF), and other pop-up approaches.

2- PCI DSS QAS A-EP (Level A-EP): It is one step above Level A, and provides better control over the UX of payment form.

While you may briefly interact with sensitive data in the UI layer, you shouldn't send it to your server or store it. In this method a payment script manages sensitive fields and the payment button. This JavaScript replaces the sensitive data with a secure token called a payment nonce before submitting your form.

Whenever I discuss these various approaches, people often inquire about their visual appearance. I mean, the most significant challenge during this journey has been assessing the user interfaces (UIs) of these different methods. Aside from a handful of screenshots and some less-than-ideal videos, I couldn't find any live demos to evaluate the UI. Additionally, it remained unclear how much more challenging it might be for businesses to upgrade their PCI compliance even by just one level.

Live Demo for Accept.js and AcceptUI

If you're interested in exploring the UI and UX of Accept.js and AcceptUI from Authorize.net's service, you can access UI demos and HTML code here:

Option 1: Accept.js, Hosted Payment Form (Requires PCI-DSS SAQ A-EP)

Option 2: AcceptUI - Hosted Payment Form (Requires PCI-DSS SAQ A)

References for more details about Accept.JS:

API of Accept Suit

Developer Guide

Comparing Workflows: Accept.js vs. Accept Hosted Page

reference from Authorize.net

Within the Accept Suite of the Authorize.net website, you'll find two different options. the Accept Suite itself is a designed section with reduced PCI DSS requirements.

However, even within the Accept Suite you'll encounter two types, as mentioned earlier.

The primary difference between AcceptJS (or AcceptUI) and the Accept Hosted Page method (which includes redirect and iFrame) lies in their workflows:

1- In the AcceptJS workflow, you receive a payment nonce instead of sensitive card data before submitting the form to server. Subsequently, the transaction can be initiated on the server side. the payment response indicates the success of the payment.
In this method, you have two options. In the first option, you can design the entire form by yourself, including HTMl, CSS and JavaScript. In the second option, when you click on the Pay button, an iframe loads and displays a popup modal whose design cannot be changed.
(I must confess: It's a rather unfortunate Material Design form with fields shamefully underlined 😔)

2- With the Accept Hosted Page method, you have to initiate payment after the user has confirmed the price and order. Then you can send a payment request to Authorize.net (including details such as the amount, order specifics). after that you received a payment token, you can display the payment form to the customer.
This form loads within an iframe or on external pages. Unfortunately, you have no much control over the UI of that iframe.
Once the user filled out the payment form and clicked the pay button of Authorize.net iframe (or page), the transaction begins and a callback (or webhook, if you ahve configured it beforehand) will be sent to you.
Subsequently, you have to make an inquiry request to the API to confirm whether the payment was successful or not.

Stable GPT: Using Interpreter for Web Development (Python Code)

Savy — Tue, 19 Sep 2023 11:45:58 +0000

It hasn't been long since Firefly was released for Photoshop. Many UI/UX and Graphic designers are now using it. However, in web development, we don't have a similar option yet.

Interpreter: Is it Firefly for Programmers?

After releasing Interpreter, a CLI tool that runs commands in a terminal environment, I decided to create instructions for GPT to see Interpreter would work with me or not.

Installing Interpreter

pip install open-interpreter

I installed Interpreter on WSL, but it can also be installed on Linux and other operating systems.

Problem: Stability and Maintaining Consistent Coding Style

I remember 5 months ago, when I decided to build my first Android application using GPT3-5. I asked GPT for UI code and it gave me a layout code. I noticed a bug and asked for it to be fixed. However, GPT sent me a completely different code with different variable names!

The obvious reason is that GPT doesn't have enough memory to retain everything I tell it. I'm searching for a solution to make GPT more stable. I'm aware of the 8k - 64k word limitation, so I need to provide GPT with instructions that are both accurate and concise.

Interpreter (GPT) Instructions

In this instruction, which I've set for GPT as "system" command, I described Project, Stack, Design System, etc.
When I run this Python file, I have a developer who understands my goals and assists me in development.

Here is my Python code which I run with the command python3 chat.py in the WSL terminal. This file is in the root folder of my Nuxt project.

import os
import interpreter
from dotenv import load_dotenv

load_dotenv()
interpreter.model = "gpt-3.5-turbo"

interpreter.api_key= os.getenv('OPENAI_API_KEY')
interpreter.system_message += """

You are my copilot developer. I want assign some codings to you.
Consider these instructions for each message:

Project Description = [
    Name: My Project Title
    Domain:  X.com;
    Market: E-Commerce Specific Field;
    Zone: North of America and Canada;
]

Specifications and Technologies = [
    CSS Framework: Tailwind CSS;
    Frontend Framework: Nuxt.js version 3.7.0;
    Design System: Atlassian Design System;
    Backend CMS: Strapi Headless system , Top of Koa framework;
    Nuxt Strapi Module Version: ^1.9.0;
]

HTML and CSS Context = [
    HTML: use Vue 3 and Nuxt 3 tags;
    Css: use tailwindcss classes or styled scopes;
    Icons: I use "@tabler/icons-webfont": "^2.34.0";
]

Nuxt 3 Architecture and Structure = [
    Vue version: ^3;
    Layers: Project uses different layers. Layers are outside of the project root;
    layouts: In `layouts` folder;
    Components: They are in the `components` folder;
    Pages: In `pages` folder;
    Styles: In `assets/styles` folder;
    File and folder naming: All files and folders should be `kebab-case`;
    Default index name: `index.vue`;
]

Purpose =  [
    Creating an E-Commerce CMS;
]

Style and Design = [
    Colors: both Dark mode and Light modes; default: system color. Pink , White, Red and other flowers like colors;
    use default color and styles of Atlassian design system;
]

Ignored Files and Folders = [
    node_modules;
    .git;
    .github;
    .nuxt;
    dist;
]

Requests for Creating a or Designing a Page = [
    - Provide a whole response with a lot of details;
    - Write necessary code as much as possible (unless user was ask for short answer);
    - Try to separate codes as layout / page / component by context of code;
    - Forget about initiating project phase and data layer phase; only consider business logic layer code and a little application layer;
    - Do not install or open IDE. you have to save files for user.component;
    - If files already exists, check it first and update it, instead on overriding contents.component;
    - Only create necessary directories;
    - Be stable and use same style;
]

Conditions: [
    If includes code request: find best path for saving that file in Nuxt structure and save it in path;
]

Initial action: [
    Explore existing files and folders;
]

"""


print(interpreter.system_message)

interpreter.chat()

Using GPT for Web Development

Why should we use GPT as a co-developer? I think that the "coding" is not our problem, Because we can use Wordpress or thousands of headless CMSs or codeless tools now. Or we can search and implement open source projects. creating a five in row game with AI is like fun research.

Development Pace

The first thing about AI Co-Developers is that they increase our coding pace. In more serious and important businesses, it's common for customers, managers or CEOs not to know exactly what they want. they require time and step-by-step progress, so we have to code at their pace.

In the past 12 years that I've been working, there were times when I deployed features so fast that customers, CTOs or CEOs didn't have enough time to test it. many times, they got offended and threatened because they thought that I might make decisions independently without respecting their decision-making.

So releasing new features everyday is so fast and can lead to problems. also big applications need a little stability and this stability is the main source of the trust.

Using AI to Find Clean Data

One of the biggest problems of programmers and today world is junk data and junk information.
So, maybe one of the most useful aspects of using AI would be the ability to search and find the needed part of data in the current jungle of shit code.

AI Memory Problem

I think biggest problem of GPT is its memory, at least for now.
8k - 64k words memory isn't enough for big projects, unless we find a way to decouple whole project into smaller parts.

Future

let's see what happens. I'm sure it won't be boring, at the very least, and it could even be beneficial for programmers.