Frequently Asked Questions

I mainly handle system development, plus enhancements and maintenance of existing systems, technical research, design, code review, business automation including RPA and AI, and IT-driven process improvement.

Scope ranges from small tools and Excel macro fixes to designing and building business systems, or joining as a technical lead. Size is not a constraint.

Yes.

Bug fixes for GAS or Excel macros, formula corrections, single-feature development, investigating stuck technical issues, and similar short, small engagements are welcome.

I have delivered work as small as around ¥5,000 in the past.

Yes.

That includes development engagements lasting over 100 months, plus long-term maintenance and technical support.

Absolutely.

We start from the current challenges, goals, and the outcome you want, including whether a system is needed at all.

The approach you first ask for is not always optimal, so I may suggest alternatives.

Yes.

Technology selection, feasibility studies, analysis of existing systems, product/service comparisons, PoCs, and similar work are in scope.

Sometimes research alone is enough; sometimes we continue into a PoC or prototype.

In principle, I estimate only after reviewing the substance.

Even a request that sounds like “one screen” can vary widely depending on the existing environment, security needs, integrations, and quality bar.

Sharing what you can about:

• what is painful now
• the outcome you want
• systems and tools you already use
• constraints already decided

helps the conversation move faster.

Either is fine.

I do not limit work to a single contract form.

We adjust based on scope, duration, and responsibilities.

Yes.

Rates vary with binding hours, working conditions, and the work itself.

For small spot jobs, pricing often starts from the rates published on my Lancers profile.

Mainly from conditions such as:

• development or research content
• technical difficulty
• phases covered
• security requirements
• sensitivity of data handled (including personal data)
• hours and binding conditions
• deadlines

For small jobs without special constraints, published spot rates on my Lancers profile are the baseline.

In principle, no.

I cover everything from small spot work to long-term engagements.

Ordinary estimates are free.

If a large pre-investigation or technical validation is required just to estimate, that research may be a separate engagement.

Yes to both.

Yes—and welcome.

I have delivered many projects end-to-end online, from meetings through delivery.

When the work requires it, yes.

Remote is the default preference.

I generally do not take engagements that assume residency.

If it is truly necessary, we negotiate days, hours, and contract terms case by case.

There are no fixed business hours or regular holidays.

I have covered long vacations and year-end periods when needed.

That is not a promise of always-on instant response; emergencies depend on capacity at the time.

From planning and requirements, through technology selection, design, implementation, testing, and maintenance—any stage.

Implementation-only work with finished specs or designs is also fine.

Yes.

For enhancements and maintenance, working on systems others built is more common than not.

Yes.

Incomplete documentation is common on existing systems.

I investigate from source, databases, and actual behavior, and can prepare materials useful for future handoff when needed.

Yes.

Experience includes investigating and enhancing older .NET environments and VB6 systems. Even for languages I do not primarily ship in (such as COBOL), I can read and investigate existing code.

Age alone does not put a system out of scope.

Yes.

I do not only accept work in a fixed language or framework set.

When maintainability, long-term support, hiring, or fit with the existing environment points to a better option than the one specified, I will propose it with reasons.

Especially strong experience includes:

• business systems
• Windows desktop applications
• server-side work
• web business systems
• RPA and business automation
• image processing
• analysis and enhancement of existing systems

Many engagements use C#; I also enjoy C++. Recently, TypeScript and Python engagements have also become more common.

Beyond coding itself, detailed system design is a particular strength.

Yes.

When the app alone is not enough, I also cover databases, APIs, servers, and cloud environments.

Yes.

Unexplained outages, performance issues, and analysis of a specific slice of existing code are in scope.

Investigating systems that “work, but nobody understands the insides” is welcome.

Yes.

That includes embedding generative AI into existing systems, business adoption, PoCs, and operating models.

“We want AI” alone is not a goal, so we first clarify what you want to improve.

No.

Generative AI is powerful in the right places, but probabilistic output can be a poor fit when absolute correctness is required.

If not using AI is the better call, I propose ordinary programs or existing services instead.

Yes.

I have developed and enhanced with UiPath and WinActor, and work on core development for a domestic RPA product.

As a sole proprietor I can also handle UiPath licensing.

Yes.

Even when people shuttle between Excel, mail, chat, and web systems, we organize the current work and consider improvements.

We do not automate everything by default; we prioritize by impact and feasibility.

You do not need to decide up front.

We review the current work and challenges, then compare benefits, drawbacks, cost, and maintainability of each approach.

Yes.

Building software is a means, not the goal.

When SaaS or off-the-shelf services are enough—or building in-house has thin upside—I propose not building.

Yes.

I avoid jargon where possible and explain technical background when it helps.

Depending on the content, yes.

Reviewing technical proposals and estimates from vendors, and joining technical meetings, are possible.

Yes.

I already provide ongoing technical consulting, system selection, process improvement, and development support in an advisory role.

Yes.

Joining projects already underway is common—often more so than greenfield starts.

I have that experience.

We organize specs, code, progress, and ownership, and address issues from both technical and process angles.

In the past that role earned nicknames along the lines of “firefighting specialist.”

Yes.

In recent years I increasingly cover design, technical decisions, code review, development direction, and support for other developers—not only implementation.

Of course.

Implementation against finished designs, or single-feature work, is fine.

Personally I still enjoy writing code.

Yes.

That includes code review, testing approaches, documentation management, CI/CD, and AI-assisted development workflows.

Long-term stability.

More than novelty itself, I weigh:

• reliability
• maintainability
• support lifespan
• future hiring
• fit with existing systems
• build and run cost

If mature technology with enough capability is enough, I am happy to adopt it.

Yes.

Rather than simply saying “this is better,” I explain trade-offs of each option.

If the goal is to proceed with the specified approach, I can work within that premise.

What is needed, yes.

Lately documentation is often prepared not only for humans but also for AI search, reference, and knowledge use.

Automate where practical, and reduce work that people must re-check forever.

Automation itself can be too costly, so judgment depends on system size, purpose, and required quality.

Strongly.

Shipping something that runs once is not the end—we design with who will maintain it, how much change is likely, and whether the stack will still be workable years later.

Professionally since around 2008—about 18 years as of 2026.

I programmed before that; the first language I touched was C.

Long involvement with business systems in construction-related industries.

That includes multi-year package core systems for building confirmation inspection bodies.

I also have RPA product development, various automation work, and enterprise system development.

Yes.

There are many engagements, so the site focuses on major ones.

Short spot jobs in particular are not all listed.

Confidentiality and similar contractual constraints.

On individual inquiry, I may share more concrete detail within what I can disclose.

Yes.

Major experience is also on this site; I can provide separate materials when needed.

Speed of decision-making and agile working style.

I sometimes team with related companies or partners when needed, but for smaller engagements the flexibility of dealing directly with an individual is an advantage.

Mainly speed of decision and response, plus flexibility.

With fewer handoffs between sales, design, technical judgment, and development, what we discuss tends to land in the actual work more directly.

Some clients work at a closer distance than typical company-to-company deals over long relationships.

I form a team with related companies or partners when needed.

For scale or specialty that is still hard to cover, I may introduce a suitable company or specialist.

Continuity risk is real when engaging a sole proprietor.

Especially for smaller systems I aim to:

• leave the customer able to manage the system
• retain source and necessary information
• prepare handoff-friendly documentation
• avoid over-dependence on one person

Depending on scale and criticality, I may propose a company or team from the start.

“NF” comes from my real name.

People sometimes guess “64” is a birthday—it is not.

I may explain the origin someday.

Working independently, it seemed useful to have a place where background and track record can be checked.

It started as a true one-pager and grew as needed information was added.

Yes.

Design, implementation, and updates are all mine.

Yes.

Games and small tools, among other things—I do not draw a hard line between programming as work and as a hobby.

I enjoy Japanese swords, fittings, armor, and related craft.

I sometimes make sword mountings myself.

For a long time I thought of myself as simply a programmer.

These days I more often cover requirements, design, technology selection, and project lead as well, so the role is closer to architect or tech lead.

I still like writing code.

Keeping promises, first.

Before technology: be clear about what I can and cannot do, and take responsibility for what I accept.

Because a bare 404 felt too bleak.

There is no deeper reason than that.