Building a Household Account Book App from Scratch with AI: Testing Devin's Capabilities and Productivity

Overview

I had been wanting to "build a household account book app," but was too busy to ever get started. So, this time, I decided to delegate the entire development process to the AI engineer Devin, without writing a single line of code myself. I verified how much it could implement, and how much development time and cost could be reduced.

Theme

For this verification, I proceeded under the following conditions:

• Develop a household account book app from scratch using only natural language
• Leave code quality and implementation strategies entirely to Devin, without human-led detailed quality checks
• All requirement adjustments and specification changes were handled via chat
• Quantitatively record ACU (Agent Compute Units) consumption and man-hour reduction effects

What I wanted to do

• Implement the basic features of a household account book app
• Measure Devin's ACU consumption and compare man-hours

The main purpose was measurement. I set the goal around how much ACU would be consumed.

What I did not do

• Excessive quality checks
• Guaranteeing functionality
• Aiming for completion (as the session would end when ACU ran out)
• Production environment construction and deployment

Since the purpose of this experiment was to see how far it could self-manage with light requests, the goal was to reach a "proof-of-concept" level.

Household Account Book App Development Session Log

In this session, I developed a personal household account book app (kakeibo-app) from scratch. Using a monorepo structure with Next.js (frontend) and Nest.js (backend), I built a full-fledged web application combining a GraphQL API, PostgreSQL, and Prisma ORM.

Completed UI

Main Features

• Income/expenditure management
• Monthly aggregation
• Category management
• Transaction registration, editing, and deletion
• Template management
• Bulk transaction registration

Tech Stack

• Frontend: Next.js 14, React, TypeScript
• Backend: Nest.js, GraphQL, TypeScript
• Database: PostgreSQL (Local: Docker, Production: Supabase intended)
• ORM: Prisma
• UI: shadcn/ui, Tailwind CSS
• State Management: Apollo Client
• Forms: react-hook-form + zod
• Development Environment: Docker, pnpm (monorepo management)

I provided the general tech stack in the initial chat, and Devin proposed the structure.

I want to build a personal household account book app.
Tech stack:
- Next.js (frontend)
- Nest.js (backend)
- GraphQL (API)
- shadcn ui (CSS framework)
- Prisma (ORM)
- PostgreSQL (assuming Supabase for production)

Development Phases and Pull Requests Created

Devin created 11 PRs in total. I defined the scope of this verification as everything from development environment setup to basic feature implementation within the available ACU.

Development Breakdown

Cost per Engineer

To compare cost-effectiveness, I calculated the estimated man-hours if done by one engineer.

• Hourly rate for an engineer: 6,000 JPY (average rate)
• Total: 46 hours of work: 276,000 JPY

I compared the measurement results from using Devin with the man-hours for one engineer. The figures for one engineer are based on estimations, accounting for general thinking and research time.

Task Request	Time Taken	ACU Consumed	Devin Cost	Engineer Man-hours (Estimated)
Phase 1: Environment Setup	20 min	2.56 ACU		2 hours
Phase 2: DB Design (Prisma schema)	5 min	1.09 ACU		4 hours (incl. requirement study/implementation)
Phase 3: Frontend UI Implementation	10-20 min	3.29 ACU		8 hours
Phase 4: Data display issue resolution	15 min	2.56 ACU		4 hours (incl. investigation)
Phase 5: Monthly aggregation enhancement	20 min	3.8 ACU		8 hours
Phase 6: GraphQL schema error fix	10 min	3.33 ACU	4,995 JPY	2 hours
Phase 7: Category management	10 min	2.08 ACU		4 hours
Phase 8: Modal display issue resolution	10 min	3.76 ACU		4 hours
Phase 9: Fix React warnings	15 min	2.15 ACU		2 hours
Phase 10: Implement transaction templates	10 min	2.37 ACU		4 hours
Phase 11: Fix template transaction display	20 min	3.24 ACU	3,330 JPY	4 hours
Total	Approx. 2h 25m - 2h 35m	30.23 ACU	8,325 JPY	46 hours

🧮 Human vs. Devin Development Productivity Comparison

Metric	1 Engineer	Devin (AI)	Difference / Reduction & Improvement Rate
Time Spent	46 hours	Approx. 2.5 hours	▲94.6% Reduction
Work Cost (Est.)	276,000 JPY (@6,000/hr)	8,325 JPY	▲Approx. 97% Reduction
Productivity Factor	-	-	Approx. 18.4x more efficient

Since the man-hours for a human engineer are estimations, the improvement rate is an approximation. However, comparing the minimum required time to the time taken across these 11 steps shows a significant reduction.

Details of Each Phase

Here is what Devin implemented for the requests in each phase, from environment setup to actual implementation and bug fixes.

Phase 1: Environment Setup

• Foundation for the monorepo structure
• Environment for running Next.js and Nest.js simultaneously
• PostgreSQL environment via Docker Compose
• pnpm workspace configuration

Phase 2: Database Design

• Prisma schema design
• Models for Users, Accounts, Categories, and Transactions
• Recurring transaction template functionality
• Foundation for monthly aggregation features

Phase 3: Frontend UI Implementation

• Authentication system (login/registration)
• Home screen
• Transaction registration screen
• Income/expenditure management screen
• Monthly aggregation screen
• GraphQL integration
• Japanese language support

Phase 4: Data Display Issue Resolution

Problem: Transactions were not displayed because there were 0 accounts and categories for new users.

Solution:

• Automatically create default accounts when a user is created (Cash, Bank Account, Credit Card)
• Automatically create default categories suitable for Japanese household budgeting (Food, Housing, Transportation, etc.)
• Improve UX of the transaction registration form

Phase 5: Monthly Aggregation Enhancement

• Two-column layout: Left (income transactions), Right (expenditure transactions)
• Edit/delete functions for each transaction
• Total amount and balance calculation
• Aggregated view by category

Phase 6: GraphQL Schema Error Fix

Problem: Values entered in /summary were not being aggregated.

Cause: Missing appropriate type decorators for Int types in the GraphQL resolver.

// Before fix
@Args('year') year: number,
@Args('month') month: number

// After fix
@Args('year', { type: () => Int }) year: number,
@Args('month', { type: () => Int }) month: number

Phase 7: Category Management

• Complete implementation of the /category page
• Create, Read, Update, Delete (CRUD) for categories
• Search and filter functions
• Color picker and icon support
• Responsive design

Phase 8: Modal Display Issue Resolution

Problem: Entered values were not displayed correctly when editing transactions on the monthly aggregation page.

Solution: Added a dynamic key property to the modal component to force re-mounting.

<TransactionEditModal
  key={editingTransaction?.id || 'edit'}
  // ...
/>

Phase 9: Fix React Warnings

Problem: "A component is changing an uncontrolled input to be controlled" warning.

Cause: When the modal was re-mounted due to the key property in PR #8, the form's defaultValues changed from undefined to a defined value.

Solution: Changed Logical OR (||) to Nullish Coalescing (??).

// Before fix
defaultValues: {
  amount: transaction?.amount || 0,
  description: transaction?.description || '',
  // ...
}

// After fix
defaultValues: {
  amount: transaction?.amount ?? 0,
  description: transaction?.description ?? '',
  // ...
}

Phase 10: Implement Transaction Template Feature

• Template management page (/templates): CRUD operations, search/filter for templates
• Bulk entry page (/templates/bulk-entry): Create transactions from templates with only amount input
• Template edit modal: Modal component for creation and editing
• Added GraphQL mutations: UPDATE_TRANSACTION_TEMPLATE, DELETE_TRANSACTION_TEMPLATE
• Home screen update: Added navigation link to template functionality

Phase 11: Fix Template Transaction Display Issue

Problem: Template transactions were not displayed correctly.

Cause:

• Incomplete GraphQL mutation response: CREATE_TRANSACTION_FROM_TEMPLATE returned a limited field structure different from regular CREATE_TRANSACTION
• Insufficient frontend cache management: Apollo Client cache was not updated after creating transactions from templates

Solution:

• Added user, account, and category relations to the CREATE_TRANSACTION_FROM_TEMPLATE mutation to unify the data structure with regular transaction creation
• Added refetchQueries to useMutation in the bulk entry page to automatically update monthly aggregation and transaction list caches after creation

Deliverables

Completed Features

Devin implemented 8 major features. In terms of precision, the quality is around 60-70%, but it is sufficient for a personal development project.

It became clear that Devin could autonomously implement up to this level using a 'proof-of-concept' approach (without detailed design). While giving detailed instructions can sometimes waste ACU, Devin is extremely useful because it can implement features autonomously with just moderate instructions.

1. User Authentication System
2. Transaction Registration, Editing, and Deletion
3. Monthly Aggregation and Chart Display
4. Category Management (CRUD)
5. Account Management
6. Responsive Design
7. Transaction Template Feature
8. Bulk Transaction Registration Feature

Number of Files Created

• Backend: 30+ files (models, resolvers, services, migrations)
• Frontend: 25+ files (pages, components, GraphQL queries)
• Config files: 10+ files (Docker, Prisma, TypeScript, ESLint)

Future Extensions and Features (Things I want to request to Devin)

Short-term Improvements

• Login features
• Implementation of transaction template features
• Data export features
• Budget management features

Long-term Extensions

• Multi-user support (family sharing)
• Expense analysis with AI
• Integration with Bank APIs

Beyond short-term and long-term development, I feel I would like to verify whether Devin can implement features by reading images or files. If I use design tools, I could achieve this through MCP integration. However, I would also like to verify how autonomously Devin can implement a UI from low-abstraction wireframes at a personal level.

Conclusion

As a result of requesting Devin to develop the household account book app, I achieved the following without writing a single line of code. I performed development by reviewing the incoming PRs, performing functional verification, and providing feedback.

One thing I felt was that the ability to implement features autonomously without detailed instructions is extremely useful. For personal development, I usually have to work during hours outside of my main job (like at night or in the morning), so I often suffer from sleepiness or mental blocks. Devin helped solve those challenges.

Although I developed this based on simple instructions for a personal project, in actual professional work, I would refine the design specifically and in detail. The clearer the instructions to Devin, the higher the quality of the intended deliverable.

Benefits of Devin

After using it, I felt that Devin covers 4 major areas:

1. It allows non-engineers (PO or PM) to conduct research via Deep Wiki
2. Since communication is browser/Slack-based, it is easy for POs and PMs to communicate
3. Devin can handle the range from design to implementation
4. Standardized tasks can be automated using Knowledge and Playbooks

I feel that the benefit of using Devin as a communication tool, in addition to utilizing it from design through implementation, is very high. Because it is browser/Slack-based, POs and PMs can use Devin to grasp the situation or investigate implementation specifications.

How to Utilize Devin

Although this is not how I used it this time, I have recently been using Devin for design and estimation as well. Tasks such as implementation design, research, and estimation can be performed efficiently by using Devin.

1. Request requirement generation and code research during the design phase
2. Provide feedback based on the design proposed by Devin
3. Request estimates for man-hours
4. Have humans make the decision on the estimate (check the provided code and scope of impact)

---

Implementation Period: July 29, 2025 - August 1, 2025
Number of PRs Created: 11 (all merged)