Automation & Technical Software Specialist focused on turning complex, repetitive, or poorly documented processes into practical and maintainable solutions.

I work across Python automation, data processing, technical documentation, software troubleshooting, and low-level Android/Linux development.

Most of my technical experience comes from self-directed projects: I identify a problem, learn whatever is necessary to solve it, build the solution, and document it so it can be reproduced and maintained.

📍 Buenos Aires, Argentina
💼 Open to freelance, contract, and collaborative opportunities

I build tools that replace repetitive manual workflows with reproducible processes.

My main example is Inventory Toolkit, a Python-based toolkit I designed and developed from scratch to automate real-world retail inventory and sales workflows.

Technologies:

• Python
• pandas
• NumPy
• OpenPyXL
• Excel
• Power Query
• JSON-based configuration
• Automated testing

I create documentation for technical projects and development workflows, including:

• Installation and setup guides
• Developer documentation
• Build guides
• Configuration references
• Troubleshooting guides
• Project architecture documentation
• MkDocs-based documentation

My documentation experience includes Android development, Git, Linux, and my own software projects.

English ↔ Spanish

I can translate and adapt technical documentation while preserving:

• Technical terminology
• Commands and code
• Configuration examples
• Project-specific context
• Developer-oriented language

I have maintained technical documentation in both English and Spanish for my own projects.

I have experience investigating complex software and development problems involving:

• Linux
• Android
• Git
• Android build environments
• Custom ROM development
• Device trees
• Linux kernels
• Development tooling

My approach is investigation-driven: reproduce the problem, understand the underlying cause, test possible solutions, and document the result.

Python toolkit for inventory reconciliation, stock processing, and Excel automation.

Inventory Toolkit originated from a real-world retail workflow where inventory analysis was heavily dependent on manual Excel operations.

The original process could take several hours per report, involved repetitive calculations, multiple data sources, and a large amount of manual work.

Nobody asked me to automate it. I identified the problem myself and progressively rebuilt the workflow.

The project evolved through several stages:

Manual Excel workflow
        ↓
Power Query automation
        ↓
Reusable processing scripts
        ↓
Inventory Toolkit
        ↓
Configurable, tested and documented toolkit

The current toolkit automates three major workflows:

• 📦 Stock Processing
• 🔄 Inventory Cross Check
• 📊 Year-over-Year Sales Analysis

Inventory Toolkit follows a strict separation of concerns:

CLI
 │
 ├── User interaction
 ├── Input validation
 └── Workflow selection
       │
       ▼
Engine
 │
 ├── Stock Processing
 ├── Inventory Cross Check
 └── YoY Sales Reports
       │
       ▼
Core
 │
 ├── Configuration
 ├── Logging
 └── System utilities

The processing engine is independent from the CLI and can be executed programmatically without the interactive interface.

Business rules are kept outside the source code through profile-based JSON configuration, allowing the same codebase to adapt to different businesses or branches without modifying the processing engine.

One of the problems encountered during physical inventory reconciliation was that scanned inventory data did not always contain a clean article identifier.

For example:

12345-261H1XL

The article portion could not safely be extracted using a fixed character length because article identifiers could vary in length.

Instead of making an arbitrary assumption and potentially corrupting the data, Inventory Toolkit compares the reading against the system's master article database and selects the most specific valid match.

If no reliable match exists, the original value is preserved:

REVIEW | 12345-261H1XL

This follows an important principle of the project:

When the available data is insufficient to determine a reliable result, preserve the information and expose the exception instead of silently guessing or discarding it.

Inventory Toolkit also includes:

• Modular architecture
• Profile isolation
• JSON-based configuration
• Automated tests with pytest
• Persistent logging
• Excel rendering with OpenPyXL
• Demo datasets with sanitized data
• Configuration validation
• Documentation covering architecture, configuration, development, and testing

View Inventory Toolkit →

My technical documentation is available through my personal documentation site:

fpsensor.github.io

It includes guides covering areas such as:

• Android ROM compilation
• Git
• Android development tooling
• CRB Android Kitchen
• Project-specific development workflows

The documentation is maintained in a structured MkDocs environment.

One of my longer technical guides documents the process of building an Android ROM from source.

It covers the workflow from the beginning:

Build requirements
      ↓
Server / environment setup
      ↓
Finding device trees
      ↓
Finding kernel & vendor sources
      ↓
Preparing the build environment
      ↓
repo initialization & synchronization
      ↓
Device tree preparation
      ↓
ROM compilation
      ↓
Output & testing

The guide is based on practical Android development experience rather than purely theoretical documentation.

Before focusing more heavily on automation and data workflows, I spent years working on low-level Android and Linux projects.

My experience includes:

• Custom ROM development
• Linux kernel development
• Kernel upstreaming
• Device trees
• Vendor blobs
• Android build systems
• Git-based development workflows
• Linux server environments
• Low-level debugging

One of my most extensive Android development projects was the Motorola Moto G51 5G (cypfq).

I developed custom ROMs and device-specific software for the device over several months, progressively debugging and improving hardware functionality through repeated test builds.

The project reached a near-stable state, with major device functionality working before development stopped after I no longer had access to the device.

• NFC stack integration and debugging
• Fingerprint implementation
• SELinux policy debugging
• Device tree development
• Vendor integration
• Rootdir configuration
• Hardware overlays
• VINTF configuration
• Kernel integration
• Touchscreen configuration
• Audio configuration
• Bluetooth configuration
• Device-specific property configuration

The public repository contains a substantial history of my contributions, including commits directly authored or committed by me.

Some examples include:

• Switch to st21nfc
• update NFC permissions
• import ST NFC stack
• import egistec stack
• adapt fingerprint and description info to cypfq
• adapt rootdir modules
• adapt overlays
• Drop duplicated VINTF entries
• commonize kernel src path

View the cypfq development organization →

An experimental project focused on moving the device's legacy Linux kernel from 3.18 to 4.9.

The project involved working with an old Android device platform and adapting the kernel and surrounding device infrastructure to support newer Android requirements.

Focus areas:

• Linux kernel development
• Kernel upstreaming
• Android compatibility
• Device-specific debugging
• Low-level system development

Contributed to custom kernel development targeting several Samsung devices and the Exynos 2100 platform.

Work included low-level kernel modifications and performance-oriented experimentation.

The project also provided experience working with an existing open-source codebase, maintaining compatibility across devices, and investigating real-world device behavior.

An experimental attempt to move the Xiaomi Mi 8 kernel from 4.9 to 4.19.

The kernel successfully reached recovery, but the project ultimately did not achieve a complete system boot due to missing platform resources.

Rather than considering the project simply a failure, it became a practical low-level debugging and Android kernel development exercise.

I am largely self-taught and most of my projects started from problems I encountered myself.

My typical workflow is:

Identify the problem
        ↓
Understand the underlying system
        ↓
Research & learn what is missing
        ↓
Build a solution
        ↓
Test it against real cases
        ↓
Document the solution
        ↓
Refactor when necessary

I particularly enjoy working on problems where there is no obvious "click here to fix it" solution.

If I don't know how something works, I am comfortable learning it.

• Python
• pandas
• NumPy
• OpenPyXL
• Power Query
• Excel
• JSON
• Bash

• Git
• GitHub
• GitHub Actions
• pytest
• MkDocs

• Linux
• Linux servers
• Android
• Linux kernels
• Android build systems

• Data processing
• Excel automation
• Inventory reconciliation
• Sales analysis
• Data normalization
• Business-rule driven processing

Spanish — Native

English — B2
Technical documentation, software development, and technical translation.

I am currently interested in freelance and contract opportunities involving:

• ⚙️ Business process automation
• 📊 Excel / Python data processing
• 📚 Technical documentation
• 🌎 English ↔ Spanish technical translation
• 🔧 Software troubleshooting
• 🐧 Linux / Android development support
• 🤖 Android development and low-level work

If you have a repetitive process, a technical problem, or documentation that needs to be created or reorganized, feel free to get in touch.

Email: gonzalo.i.daroqui.r@gmail.com

LinkedIn: Gonzalo Ignacio Daroqui Rodriguez

GitHub: FPSensor

Website & Documentation: fpsensor.github.io

I also enjoy urban and architectural photography.

You can find some of my photography on Instagram.

I like solving problems that don't come with a manual.