DEV Community: Pytagotech

Approval Workflows Are State Machines

Pytagotech — Sat, 23 May 2026 11:08:30 +0000

Approval workflows often look simple in conversation.

"User submits a request, manager approves it, then finance processes it."

In real software, that sentence hides a state machine.

If the states are not clear, the workflow will become hard to test and hard to support.

Start with states, not buttons

A common mistake is designing the buttons first:

Submit
Approve
Reject
Revise
Cancel
Process

Buttons are actions. They should move the request between states.

The states might be:

draft
submitted
under_review
revision_requested
approved
rejected
cancelled
processed

The exact names depend on the business, but the principle is stable.

Every action should have a valid source state and target state.

Invalid transitions matter

The system should know what is not allowed.

For example:

a rejected request cannot be approved without reopening it
a processed request cannot be edited directly
a draft request should not appear in manager approval
a cancelled request should not trigger finance work
a revision request should return to the original submitter

Writing these rules explicitly reduces bugs.

It also makes the admin interface easier to explain.

Audit logs are not optional for serious approvals

Approval workflows need history.

At minimum, store:

who performed the action
previous state
next state
timestamp
note or reason
related attachment if needed

This helps when someone asks:

"Why was this approved?"

Or:

"Who requested the revision?"

Without a log, the team goes back to chat screenshots.

Notifications should follow state changes

Notifications are often easier when they are tied to state transitions.

Examples:

submitted -> notify manager
revision_requested -> notify submitter
approved -> notify finance
rejected -> notify submitter
processed -> notify requester

This is cleaner than scattering notification logic across random button handlers.

A simple test table helps

For each state, write:

Current state	Allowed action	Next state	Actor
draft	submit	submitted	requester
submitted	approve	approved	manager
submitted	reject	rejected	manager
submitted	request revision	revision_requested	manager
revision_requested	resubmit	submitted	requester

This table becomes a practical tool for product, engineering, QA, and support.

Approval workflows are business logic.

Treating them as state machines makes that logic visible.

The Spreadsheet Replacement Trap

Pytagotech — Sat, 23 May 2026 11:07:32 +0000

Many internal software projects begin with a sentence like:

"We want to replace this spreadsheet."

That can be a good starting point.

But it can also be a trap.

If the new software only copies the spreadsheet into a web interface, the team may end up with a slower spreadsheet.

Spreadsheets are flexible for a reason

Spreadsheets survive because they are useful.

They are fast to create, easy to edit, and flexible enough for messy processes.

That flexibility is also the problem.

As the business grows, spreadsheets can create:

duplicate versions
hidden formulas
unclear ownership
manual copy-paste work
weak permission control
no audit trail
inconsistent status names
fragile reporting

The goal of software is not to punish the spreadsheet. The goal is to keep what works and fix what breaks at scale.

Do not copy the columns blindly

Spreadsheet columns often contain history, workarounds, and temporary logic.

Before turning them into database fields, ask:

is this field still needed?
who owns this data?
is it input or calculated output?
can it be derived from another record?
does it represent a status?
should it become a separate table?
should it be locked after approval?

This is where many simple-looking projects become real software design.

Spreadsheets hide workflow inside cells

A spreadsheet may contain:

color-coded statuses
comments as approval notes
copied rows as history
separate sheets as branches
formulas as business rules
file names as document references

Software should make those rules explicit.

If the spreadsheet has a yellow row meaning "waiting for owner approval", the system probably needs a real status.

If a copied row is used to preserve history, the system probably needs an audit trail.

Replace the pain, not the tool

The better question is:

"What pain does the spreadsheet create now?"

Possible answers:

too many people edit the same file
reports take too long
owner cannot see current status
approvals are not tracked
stock numbers are not trusted
data has to be copied into another system

Those pains decide the software scope.

A good first replacement is narrow

Instead of replacing the entire spreadsheet universe, start with one workflow:

stock movement
approval request
customer follow-up
order status
project tracking
field reporting

Then build the system around clear data ownership, status, history, and output.

The goal is not to make a prettier spreadsheet.

The goal is to make the work more reliable.

A Mobile App Usually Needs an Admin System First

Pytagotech — Sat, 23 May 2026 11:06:56 +0000

Many business mobile app requests start with the user-facing app.

That makes sense. The app is what customers or field teams will touch.

But for many projects, the mobile app is only the front door.

The admin system behind it decides whether the app can actually operate.

A mobile app creates data

When users interact with a mobile app, they create work for the business:

bookings
orders
payments
support requests
field reports
document submissions
location updates
member activity

Someone or something must process that data.

If the admin side is not designed, the mobile app can become a cleaner-looking way to create operational mess.

The admin workflow answers the real business questions

For each mobile action, ask:

who receives this?
what status should it enter?
who can approve or reject it?
what happens if the user edits it?
when should a notification be sent?
what should be visible to the user?
what should stay internal?

These answers shape the backend, database, notification logic, and admin UI.

They also prevent the mobile app from becoming a disconnected interface.

The first version may not need every mobile feature

Mobile apps can become expensive quickly because they often include:

authentication
push notifications
media upload
offline behavior
payment flow
user profile
admin panel
API
security rules
app store release work

The first version should focus on the core repeated behavior.

Examples:

booking and confirmation
field checklist and photo upload
membership access and history
customer request and status tracking
private team communication

If the user does not need repeat access from a phone, a responsive web app may be enough.

The admin panel should not be an afterthought

The admin panel is where the business manages the app.

It needs practical screens:

list of submissions
filters
detail page
status changes
notes
user management
basic reporting
export if needed

These screens may look less exciting than the mobile app, but they are often where the operational value lives.

A useful mobile app is a system, not only an app

When planning a mobile app, include:

user action
backend data model
admin workflow
notification rules
support process
release and maintenance plan

That gives the app a better chance of being used after launch.

Pytagotech builds Android, iOS, booking, membership, field operation, and admin-backed mobile app projects from Indonesia.

Reference: https://www.pytagotech.com/en/mobile-app-development-indonesia

Customer Portals Should Remove Repeated Admin Work

Pytagotech — Sat, 23 May 2026 11:06:18 +0000

A customer portal often starts with a simple idea:

"Customers should be able to log in."

That is a feature. It is not yet a product reason.

The better question is:

"What repeated admin work should the portal reduce?"

A portal should have a job

Customer portals can support many workflows:

booking
order status
service history
invoices
documents
support tickets
account data
membership benefits
partner requests

But the first version should not try to do everything.

It should remove one clear pain.

For example:

customers keep asking for status updates
admin keeps requesting the same documents
customers need repeat bookings
partners need to submit requests in a structured format
service history is scattered across chat

That is where a portal starts to make sense.

Login is a cost

It means users need accounts, passwords, recovery flows, and trust that the portal is worth returning to.

So the portal must give users a reason to come back.

Good reasons include:

seeing status without asking admin
reusing saved data
accessing private documents
checking history
managing requests
receiving clear next steps

If the user only needs to contact the company once, a portal may be too much.

The admin side matters as much as the customer side

A portal fails when the customer interface is built but the admin workflow is unclear.

Admin needs to know:

where new requests appear
who handles them
what status means
when customers get notified
what can be edited
what is visible to customers

Without this, the portal creates another inbox instead of reducing work.

Keep the first portal narrow

A practical first customer portal might include:

customer account
request form
status tracking
admin review
message or note history
document upload
notification

That is enough if it removes repeated admin work.

Later versions can add payments, more roles, integrations, reporting, and deeper self-service.

The portal should change behavior

A portal is successful when:

customers stop asking the same status questions
admin stops retyping the same data
requests become easier to prioritize
the business has a clearer record of customer activity
support becomes less dependent on memory and chat history

That is a stronger goal than "we have a login page."

Pytagotech works on customer portal systems for booking, service history, partner requests, document access, and account workflows.

Reference: https://www.pytagotech.com/en/customer-portal-development

Inventory Software Starts With Movement History

Pytagotech — Sat, 23 May 2026 02:53:21 +0000

The most common inventory question is simple:

"How much stock do we have?"

But the more important question is often:

"Why does the system say that?"

That is why inventory software should not start only from the current quantity. It should start from movement history.

Current stock is a result

Current stock is not a primary fact.

It is the result of movements:

opening balance
purchase
sales
transfer
return
adjustment
damaged item
stock opname correction

If the system only stores the latest quantity, it becomes hard to explain mistakes.

When someone asks why the quantity changed, the system has no story.

Movement history creates trust

A good inventory system should answer:

what changed?
when did it change?
who made the change?
from which location?
to which location?
what document or transaction caused it?
was it an adjustment or a normal movement?

This does not need to be complicated in the first version.

Even a simple movement table is better than a black-box quantity field.

Dashboards come after the movement model

Many inventory projects want dashboards early:

low stock
fast-moving items
branch stock
stock value
movement trend

Those are useful.

But if the movement model is weak, the dashboard will only summarize weak data.

The first design decision should be the stock ledger, not the chart.

Avoid editing stock directly

Direct stock editing is tempting because it feels simple.

But it creates problems:

no audit trail
no reason for changes
no separation between correction and transaction
no confidence during reconciliation

A better pattern is to create an adjustment movement.

The quantity still changes, but the reason is visible.

A practical first inventory scope

For a first release, the scope can be modest:

item master
category or unit
warehouse or branch
stock movement
movement reason
user history
low-stock indicator
basic export

That is already useful if the team records movement consistently.

Advanced features can come later:

barcode
purchase order
supplier management
stock valuation
batch and expiry
integration with sales
forecasting

Inventory software should make the stock number explainable.

If the team trusts the movement history, they are more likely to trust the current quantity.

Pytagotech's inventory software page covers this kind of practical first-release thinking:

https://www.pytagotech.com/en/inventory-management-software-development

The First Version of Internal Software Should Be Boring

Pytagotech — Sat, 23 May 2026 02:52:22 +0000

Internal software is not judged like a public landing page.

It does not need to impress strangers in five seconds. It needs to help a team do real work every day.

That is why the first version should often be boring.

Boring means clear. Boring means stable. Boring means the workflow is obvious enough that the team does not need a long explanation.

The first release is not the final system

Teams often overload the first version because they are afraid of missing something.

They add:

complex roles
advanced dashboards
multiple approval levels
notification rules
bulk imports
exports
mobile views
customer-facing modules
long configuration screens

Some of these may be needed later.

But if everything lands in the first release, the team has no chance to learn from real usage.

Internal tools should reduce confusion first

The first release should answer a narrow operational question.

Examples:

Can we see stock movement clearly?
Can we stop losing approval requests in chat?
Can the owner see daily activity without waiting for a manual report?
Can field staff submit updates from one place?
Can customers check request status without asking admin?

If the answer is yes, the system is already doing valuable work.

Boring screens can be high-value screens

Some of the most useful internal software screens are not visually exciting:

a clean table with filters
a reliable status log
a detail page with history
a simple approval button
a form that prevents missing data
a dashboard of exceptions

These are not flashy features.

But they help teams move work forward.

The danger of building for the demo

A demo rewards visible features.

Daily use rewards clarity.

Those are different things.

If the project is designed mainly to look complete in a demo, the software may become too broad and too shallow.

The team may still go back to chat and spreadsheets because the new system does not match how work actually moves.

A better first release test

Before approving the first release scope, ask:

will one team use this every week?
does it replace or reduce one manual process?
does it create a clearer source of truth?
can support handle questions after launch?
is there a clean path for version two?

If the answer is no, the first release may be too vague.

Boring internal software is not a lack of ambition. It is a sign that the team is starting with operational reality.

Your Dashboard Is Only as Good as the Input Flow

Pytagotech — Sat, 23 May 2026 02:51:23 +0000

Dashboards are attractive because they promise visibility.

Revenue, inventory, tasks, tickets, sales, team performance, branch performance, customer activity: put everything on one screen and the business looks easier to control.

But many dashboard projects fail for a simple reason.

The dashboard is built before the input flow is trustworthy.

A dashboard does not create truth

A dashboard only displays what the system knows.

If the data is late, duplicated, incomplete, or entered by the wrong person, the dashboard becomes a faster way to see messy information.

Common symptoms:

the owner still asks for manual confirmation
the team still exports data to check it elsewhere
different departments disagree with the numbers
the dashboard is opened during meetings, but not trusted for decisions
users blame the dashboard when the real issue is the input process

The problem is not always the chart library or the UI.

Often, the problem is the operational path before the chart.

Start with boring questions

Before building dashboard cards, answer:

where does the data come from?
who is responsible for entering it?
when should the data be updated?
what fields are required?
what is the correction process?
which number is the source of truth?
who is allowed to approve or lock data?

These questions sound boring, but they decide whether the dashboard will be trusted.

The best dashboard work may happen outside the dashboard

For an operational dashboard, the highest-value work is often:

standardizing form fields
removing duplicate input points
creating clear statuses
adding an audit trail
assigning ownership
validating required data
making corrections visible

After that, the dashboard has something solid to summarize.

Build the first dashboard around decisions

A dashboard should not be a wall of numbers.

A useful dashboard supports a decision.

For example:

Which branch needs attention this week?
Which stock items are below threshold?
Which approvals are blocked?
Which sales activities are not followed up?
Which field reports are missing?

If a card does not support a decision, it may be decoration.

That does not mean every dashboard must be minimal. It means every metric needs a reason.

A simple dashboard can be stronger than a large one

The first version may only need:

five key metrics
a table of exceptions
a date filter
a status breakdown
one export
links into the underlying records

That is enough if the team can act from it.

The purpose of a dashboard is not to prove that the system has many charts. The purpose is to make operational reality easier to read.

Pytagotech builds dashboard systems for businesses that need owner reporting, KPI tracking, operational visibility, and practical first releases.

Reference: https://www.pytagotech.com/en/business-dashboard-development

Build the Workflow Before the Feature List

Pytagotech — Sat, 23 May 2026 02:48:39 +0000

Many software projects start with a feature list.

Those features may all be useful, but they do not explain the business problem yet.

For custom software, the feature list is often the second document. The first document should describe the workflow.

Features are easy to name

It is easy to say "we need a dashboard."

It is harder to answer:

who enters the data?
when is the data considered valid?
who can change it?
what status should stop the next step?
what decision does the owner make from the report?
what happens when the data is wrong?

If those questions are unclear, the dashboard is only a surface. It may look useful in a demo, but it will not be trusted during real operations.

A workflow-first scope is usually smaller

When you map the workflow first, the first release often becomes more realistic.

Instead of building a large "business platform", the first version may become:

request submission and approval status
stock movement and audit trail
customer booking and admin confirmation
field report input and daily summary
partner portal with document access

That is not less ambitious. It is more controlled.

The first release should prove that the system can survive real usage.

The workflow tells you what not to build yet

Good scope is not only a list of what to build.

It also says what can wait.

For example:

advanced analytics can wait until the input flow is reliable
mobile apps can wait if the main user is still an office admin
role complexity can wait if the team only has two real permission levels
exports can wait if the first decision is visible inside the system

This keeps the product from becoming heavy before it becomes useful.

Developers should ask operational questions

Developers do not need to become business consultants.

But we do need to understand the work that the software will replace or support.

Useful questions include:

what is currently done in chat?
what is currently done in spreadsheets?
what is repeated manually every week?
what causes late decisions?
which data is trusted and which data is often corrected?

These questions make the code easier to design because the domain becomes clearer.

Practical takeaway

Before writing a feature list, write the workflow in plain language.

Use this structure:

Trigger: what starts the process?
Actor: who does the first action?
Data: what must be captured?
State: what status changes?
Decision: who approves, rejects, or moves it forward?
Output: what report, notification, or next step is needed?

If that map is weak, the feature list will probably be weak too.

At Pytagotech, this is how we prefer to start custom software discussions: workflow first, features second, release plan third.

Reference: https://www.pytagotech.com/en/software-development-company-indonesia

Before Building Custom Software, Map the Workflow First

Pytagotech — Sun, 10 May 2026 05:25:52 +0000

Many custom software projects start with a feature list.

Those features may be useful, but they do not explain the real problem yet.

For many growing businesses, the actual issue is not "we need software." The issue is usually more operational:

approvals take too long because decisions are scattered across chat
sales, stock, and service data live in separate spreadsheets
owners wait for manual reports before making small decisions
customers repeat the same information because there is no shared record
field teams submit updates late because the process is not phone-friendly

When a business jumps straight into features, the first release often becomes too large, too vague, or too hard for the team to adopt.

At Pytagotech, we prefer to start with workflow mapping before writing a feature list.

A workflow-first approach is slower at the beginning, but safer later

The goal is not to document everything in the business.

The goal is to find the first operational bottleneck that is worth solving with software.

For example:

If the issue is slow approval, the first version may only need request submission, approval status, notes, and notification.
If the issue is stock visibility, the first version may only need item records, stock movement, branch view, and a simple report.
If the issue is customer follow-up, the first version may only need lead status, activity history, ownership, and next action.
If the issue is field reporting, the first version may only need mobile input, photo upload, location context, and daily summary.

This is different from trying to build an ERP, CRM, dashboard, and mobile app all at once.

The first release should prove the system can be used

A custom system is only valuable if the team actually uses it.

That means the first release should be small enough to launch, but complete enough to reduce one real pain.

Before deciding the scope, we usually ask:

Who uses this workflow every day?
What data is entered first?
Who needs to review or approve it?
What status should be visible?
What report does the owner actually need?
Which part can wait until version two?

These questions make the scope more realistic.

They also prevent a common mistake: building software that looks complete in a proposal but feels heavy during daily use.

Dashboards should not be built before the data flow is clear

Many businesses ask for dashboards early.

That is understandable. Owners want visibility.

But a dashboard is only useful when the input flow is reliable. If the team still records data manually in different places, the dashboard will only display messy data faster.

In that situation, the first step may not be a dashboard.

It may be:

standardizing data input
defining required fields
deciding who owns each update
making approval status visible
reducing duplicate records

After that, the dashboard becomes more trustworthy.

A practical first scope is often better than a large first scope

The safest software projects usually have a clear first release.

Not because the business lacks ambition, but because adoption matters.

A practical first release gives the team a chance to:

test the workflow with real users
notice what still feels unclear
reduce manual work in one area first
improve the system based on usage, not assumptions

That is how custom software becomes a tool, not just a finished project.

Where Pytagotech fits

Pytagotech is a software house based in Malang, Indonesia. We help businesses build practical digital systems such as dashboards, portals, inventory tools, approval workflows, lightweight CRM, booking systems, and mobile-backed operational tools.

Our approach is simple: understand the workflow first, define a realistic first scope, then build in stages.

If you are comparing options for a custom software project, these pages may help:

Software development company in Indonesia: https://www.pytagotech.com/en/software-development-company-indonesia
Selected work: https://www.pytagotech.com/work
Starting price references: https://www.pytagotech.com/pricing