You have a team or a product but you don't have technical expertise. This starts with the audit of your project as a separate stage with an overview report about your team, product and situation. You will be able to make informed decisions based on it.
If you decide to proceed, we agree about exact scope of work, powers, responsibilities and time frames, after I provide temporary CTO/crisis manager experience. This involves solving challenging technical and organizational puzzles to make things work, I will need at least 16 hours a week commitment, maybe more. I might refuse to work on a project if I don't understand the science/technology/business well enough.

• Communicating with stakeholders

• Managing requirements and the scope of the project

• Managing ongoing work and schedule

• Managing a team as a technical and/or people manager

• Investigating existing processes, making them work, proposing and implementing new processes

• Reporting

Example:

I client of mine had a social media startup website. They worked on a new version for a year but when tried to release, they somehow simply couldn't. This lasted for half a year.

I investigated the situation and figured out the problems:

• Even though the outsource developers team actually worked, they didn't perceive themselves responsible for the product. Instead they understood the collaboration as a profitable ongoing time to money exchange. They liked things as they were and because of this didn't guide the business to the project completion.

• The business partners were too excited about features and provoked release feature creep instead of setting exact scopes and focusing on making the release happen. It's either something and now or perfect and never.

• The business partners simply didn't invest enough time and attention to control the development process. This resulted in the dev team picking whatever work that felt better instead of following the priorities leaving a heap of actual release blocker tasks untouched. This also resulted in tangible slack in dev team.

I released this in a couple of months. Things I did:

• Communicated the state of things to the stakeholders;

• Formalized actual release scope to make work finite;

• Came up with a practical management process with regular status meetings and lightweight reports which was viable for both the business and the developers;

• Communicated the changes in how we work to the team;

• Figured the minimum changes to the tools used to make work prioritization, scope and work tracking possible;

• Audited the work done on an ongoing basis speeding things up by removing the 30-50% slack;

• Ran the things as an operations manager to completion.

This is often needed when making a purchase decision and often involves figuring out things like:

• What's actually there and what's not;

• What else you need to request from the previous team (this one is important!);

• What is the quality of the code;

• How practical is the use of technology in place;

• Answers to the questions you formulate when we are agreeing on the scope of research.

I deliver a report containing answers to your questions and also the basics like what parts the application consists of, what technologies are used what problems and risks are with factual references and overall assessment based on my experience.

Example:

One of my customers needed to make a purchase decision of a point of sales system. They needed to understand:

• The points above, e.g. what's there etc;

• What are the mobile app limitations and perspectives;

• Is it practical to continue developing this;

• What costs of migrating to a newer technology would be;

• Is it cheaper to do the same in-house instead.

I provided the report with all the details.

Can be used when validating a contractor and/or the work they did at certain stage. I can share many stories about clients being misled by the teams, "Tales from the Crypt" I call them. I'm capable of auditing a complex ongoing process, but I can also audit requirements or an estimate to figure out if they are realistic.

Figuring out:

• Factual task achievement, including in contractual sense;

• The actual amount of resources/people involved which is often different from what the team claims/bills;

• The quality of actual development process;

• The quality and maintainability of the code;

• Where things are going;

• Answers to your questions.

I deliver a report containing answers to your questions and also the basics like what parts the application consists of, what technologies are used, how things look like in formal sense, what problems and risks are with factual references and overall assessment based on my experience.

Example:

This was a entertainment web portal startup. The outsourced team claimed they finished certain stage after a demo to the client and sent the invoice.

During the audit I figured that:

• The team actually had less than 1.5 full time equivalent resources involved instead of 3 they billed for;

• The engineering culture were below low e.g. they had blank commit messages only and a .zip file of an older version of the same repository committed alongside with other code;

• What they showed during the demo was actually some HTML pages with JavaScript and JSON backend stubs instead of completed backend they claimed;

• A subsystem developed by another independent contractor was done surprisingly well.

The client leveraged the report during the negotiations with the contractor.

You are starting you work and need someone to lay out the foundation to leverage more budget resources later. Or you have an idea and want to validate if it works. Or you have you own design and just want to independently validate it. This consulting work usually involves:

• Agreeing on what is to be build and figuring out the scope;

• Agreeing on the priorities and requirements;

• Considering different design choices;

• Creating a working proof-of-concept (PoC).

The deliverable can be something starting from a investigation report with optional sketches or diagrams to a working PoC.

Example:

My client needed to change a payment system backend and was concerned about possible switch to production risks. I researched possible scenarios and we agreed on the course of action. I set up transaction traffic replication to test the new system side-by-side with the old one cross-checking databases. First, we switched to the new backend via the replicating proxy continuing to replicate traffic to the old one keeping it a hot standby. In the end we switched smoothly via DNS with TTL pre-set to a short period ahead of time.

You have something and you need it done. Depending on what it is I might:

• Refuse especially if I'm not competent in the area;

• Do it myself;

• Find someone;

• Do the work with help of other developers being responsible for the result.

Why to ask more expensive developers to do something while Nepal developers offer lower rates? Some common reasons are:

• Paying lower rates means paying lower rates, not necessarily getting the stuff done;

• 20$ * 5 = $100 * 1 - in the end you pay for the scope not the amount of hours;

• Software shops love to start from scratch, I'm competent enough to start from where you are;

• If you are reading this, you probably already have a fair idea why.

Example:

One of my clients had a legal form software they needed to somehow integrate with multiple document management systems like SharePoint. I figured out that they have Visual Basic for Applications (VBA) macro ability and staff competent in writing such macros. I came up with the concept and provided a minimal and very cost effective COM VBA driver command-based implementation. I generated comprehensive user documentation from comments and provided auto-tests to check that the driver worked reliably. They used their own employees to provide actual work flow mechanics with VBA macros. As a result of this granular approach, they were able to integrate their software with 3 other systems with very minimal changes.

There is a bunch of tasks related to rehosting applications in a an application-aware way. This includes migrating both to and from the cloud or between clouds, say from Azure to GCP to save on Linux infrastructure or from GCP to Azure to leverage MS ecosystem.

Usually, something among the following is done:

• Lifting and shifting;

• Dockerization / containerization/adapting for a given cloud provider;

• Resolving networking and DNS problems via amending the config or the application;

• Re-engineering how the storage is used.

Examples:

• Migrating to Azure or GCP to optimize staff costs and/or for infrastructure durability and/or scalability;

• Migrating from a cloud provider to bare metal Kubernetes to save on costs;

• Switching from VMs to Kubernetes.

Sometimes you cannot just lift and shift or rehost. An update of underlying technology or changing application topology might be required. Think splitting monoliths to microservices. This also include migrating parts of applications, say swapping from MongoDB to CosmosDB and back. All things involved like data and users are considered in the process. I used to conduct a class about migrating Microsoft workloads to OpenShift. My preferred way of action is baby steps low-touch approach to find the best stage where to stop and minimize risks.

Common activities are as follows:

• Investigation, architecture review with possible options and their pros and contras;

• Rearchitecting e.g. monolith to microservices;

• Re-engineering the application topology;

• Resolving networking and DNS problems via amending the config or the application;

• Re-engineering how the storage is used;

• Data migration.

Examples:

• Splitting an ASP.NET monolith in a bunch of ASP.NET Core microservices with WCF being replaced with gRPC;

• Moving .Net Framework + MS SQL VM-based app to container-based .NET Core + MS SQL Server running in a container on Kubernetes.

• Moving multi-part application to the cloud with different parts using different approaches e.g. lift & shift, containerizing, replacing with SaaS;

• Organizing migrating a complex product including co-existence strategy;

• Auditing a migration project.

It's hard to start to doing Continuous integration or Continuous delivery if you never did this. I will:

• Coach the team on how it's done;

• Monitor the progress and support them down the road;

• Help with setting up tools e.g. Azure or Google Cloud Platform for hosting and Azure DevOps, GitHub or GitLab as CD platform.

Examples:

For a .NET desktop financial software team.

• Conducting a 1-day Azure DevOps training to quick-start the team in their journey;

• Setting up project management with Azure Boards;

• Setting up Azure environment;

• Building a starting point CD pipeline with Staging and Production environment for their server-side part;

• Consulting occasionally during the later period.

Want to save on the cloud? Using my deep understanding of Azure and GCP I often can optimize cloud environments help my client pay less.

Common activities:

• Research to understand the picture; send me an e-mail, I might decide to do this part partially or fully for free;

• Dropping unused stuff;

• Right-sizing and right-tiering of resources;

• Stopping and scaling resources on schedule;

• Setting up fine-grained costs tracking.

Example:

I shrank Azure monthly bill of one of my clients deleting resources and doing right-sizing 2.5 times in 2 hours.

This might involve doing things you need NOW or yesterday under time pressure.

• Fixing a broken production;

• Force-coding to meet a deadline;

• Setting something up real fast to help your team save time on this;

• Calling in an experienced fire team.

I might charge extra for urgency if I need to reschedule something and will charge extra for work at night. Doing hard work at night doesn't sound too prestige. Why do I even do it? Well, I'm confident in my expertise and not afraid of challenges. This lets me quickly prove myself and get a foot in the door. Historically, I found most of my clients via recommendations, but helping with something urgent was the close second.

Examples:

• A CEO deleting an "old" domain zone,

• a website going down after being visited by "fast" Google bot,

• a payment service down after a certificate expiration (classic!),

• a Windows patch bringing an intranet system down because of converting nanoseconds to String differently,

• Active Directory sync suddenly breaking leaving users without access,

• .NET application breaking after being hit by production traffic because of loading entire SQL DB into RAM by accident,

• circular references in ASP.NET website Just in Time views compilation,

• Redis changing it's TLS requirements on Azure,

• His Majesty NullReferenceException,

• And, of cause ,"it just went down; I didn't touch anything".