I’m trying to think of a new business name for my consulting company, msoftware. The name was something I put together during the pandemic when I split off from the other consulting company I found with another developer. After deciding to split the companies up, I didn’t have a lot of time to figure out a good business name. The first letter of my last name + software seemed good enough to form the LLC, get the bank accounts set up and continue moving with the existing contracts that were in place.
Since 2020, the msoftware business continues to grow purly via word of mouth and connections I’ve made along the way. But, I’ve never really been happy with the name msoftware. It feels kind of lazy and it’s overly generic which makes finding us online more difficult. A Google search for msoftware doesn’t return the msoftwaredev.com website anywhere. That’s something I’m also working on in Google Search Console – hopefully that is fixed in the next couple of days and you can start to see msoftare results.
I remember why I chose msoftare as the business name: it was super easy to create. There wasn’t time to work on a branding project so I just threw out what came to me. Now that I’m trying to create a new business name I’m finding it very difficult to do. A few of the challenges are:
There are hardly any domain names and business names available. So many of the ideas I’ve come up with have already been taken.
Nothing feels right. The names I’ve come up with have been pretty generic and felt pretty cheesy.
Creating something out of nothing but having unlimited possibilities is impossible. When I sit down and write the business values and summary the business names that come up feel very corporate.
Specifically what msoftware does is we work with clients to develop a technology strategy and seamlessly integrate data sources into clients’ environment or in the cloud. Overall, we focus on providing data-driven solutions to empower clients to make informed decisions that drive their business forward via custom software implementations or out of the box solutions. It all depends on the client, their set up and their budget.
I tried using ChatGTP for inspiration but was less than thrilled with the responses I got. Here are 10 business names generated by ChatGTP using the prompt from the paragraph above:
Insight IQ
Decision Dynamics
DataFlow Solutions
SmartStats
Metrics Mastery
Strategy Surge
Knowledge Keys
Analytics Advancements
Impact Insights
Precision Progress
Nothing that I’m really digging at the moment. But I suppose this isn’t an overnight thing that can just happen. Though I wish it were, it would make the process a whole lot easier. So, I’ll continue workshopping different business names, but in the mean-time we will continue to move foward as msoftware.
When I’m explaining a new feature or work item to other developers I get into the habit of thinking the person I’m talking with has all the information about the client or project that I do. It’s far too easy to assume that they understand every detail of a project or client or know the history behind them, but in reality they don’t know what I haven’t told them yet. A fact I often forget about. Especially with remote workers, typing things out in detail is a lot more time consuming and takes more effort then if we were sitting at a table next to each other where you could stop me mid sentence to ask what I’m talking about. That’s hard to do in a chat message.
Everyone has different knowledge and understanding of any given project we’re working on, so I try to keep the thought that nobody knows what I’m talking about at the front of my mind when trying to communicate with my coworkers. This helps me to provide a clear and detailed background, instructions, expectations and to make sure the people I’m working with have the information they need to do their jobs. One of the most important things I do is to avoid assuming people know what I’m talking about. This works well for both work and my personal life. I’ve learned never to assume that the person on the other end of the keyboard or table understands every detail of the thing we’re talking about or knows the history behind it. Instead, I have to remember to slow down and take the time to provide context and background information, even if it seems trivial to me.
Providing details is key to effectively communicating what I’m talking about. I make sure my instructions are clear, concise, and easy to understand. Depending on the audience, I’ll try to avoid using technical jargon or acronyms that people might not be familiar with. This works well in the organ transplant space where acronyms are everywhere.
So, in the end I try to reminder to make sure everyone knows what I’m talking about and that being effective communicator is crucial to the success our projects. Avoiding the assumption trap and providing details, no matter how much extra typing I have to do, I’m able to ensure we’re all on the same page and working toward the same goals. With that clear communication, we’re able to build great things and solid high-quality products without wasting client dollars asking question over and over again.
This year marks the eighth year I’ve been on my on as an indie developer so I wanted to write about the benefits of being a software consultant. During my time on my own I’ve worked independently as a freelancer then co-founder/partner in a small consulting company to being the principal engineer of my own software consulting company, msoftware, where I am now. Being a software consultant has a lot of benefits for people who decide to pursue this career path. Whether you’re working as a freelancer or as part of a consulting firm, the skills and experience you gain as a consultant can be applied to a wide range of industries and projects. Many of these skills don’t necessarily come from being a consultant, specifically, but from running any type of business. I actually attribute a lot of these skills to running my own t-shirt company.
Flexibility: One of the biggest benefits of being a consultant is the flexibility – both in terms of your time and projects you work on. You have the ability to choose which projects you take on and when, giving you a nice freedom to balance work and life. Additionally, you can work from anywhere with an internet connection, allowing you to travel, work from home, at a client or from a local co-working space as desired.
You wear many hats: As a consultant, you have the opportunity to work on a variety of projects and with different clients who all can different technology stacks. Clients look to you as the person who can solve it all. Front end, back end, database, marketing, email, SEO, hosting and pour over coffee. Some of the projects I’ve worked on in the last six months have been integrating with the Shopify e-commerce API, a data visualization React app of organ transplant centers around the country, a C# WebAPI interfacing with FinTech APIs and an Angular client dashboard. This diversified experience can help you build a well-rounded skill set and expand your knowledge base in a way that might not be possible if you were working in a single company or industry.
Career Growth: Consulting offers numerous opportunities for career growth and advancement. You are continuously build your skill set, take on new challenges, and expand your network by working with different clients and other consultants. It takes work to grow in the consulting world, however. I’m constantly learning new technologies and skills as well as networking. Like any technology position, you need to stay up to date in order to continue to grow.
High Demand: The demand for consultants is pretty high, both freelance and contractors, and some say is expected to increase as technology continues to advance. As a consultant, you’re likely to have a steady stream of work if you stay up to date and can command higher rates for your services in areas where there is a greater need.
Independence: I was never one for authority, so being a software consultant offers a level of independence that I’ve never had as a regular W-2 employee. As a consultant, you are your own boss and have control over your own workload and schedule – to an extent. Even though there is a lot of independence you’re still at the mercy of your clients. That means deadlines, office visits and budgets are still very much a reality. However, the independence of consultant allows you to focus on the work that you enjoy and feel most fulfilled by. Not to mention the ability to work from a Mexican beach in February.
In the end, being a software consultant is pretty great if you thrive working independently and don’t mind the sales aspect of the job. With its flexibility, variety of technologies, career growth opportunities, high demand, and independence, it is a great choice for those looking to step out on their own.
A request I get from clients that do heavy processing with R is they want to migrate from R Shiny to a modern web framework like React, Angular or Vue. Their setup usually consists of websites running in a R Shiny package that connects to a database and returns a result set on the Shiny framework back to the client. Your basic CRUD type application, essentially. Usually displaying the result set using a charting library like D3.js or HighCharts to display the results sets in nice graphs. Now that I’ve built multiple systems with these types of clients I have a good understanding of the problem, type of architectures involved and how to improve this system to take advantage of the flexibly gained from some of these modern web frameworks.
R Shiny is a great package that allows researchers, statisticians and developers to build interactive web apps using the R programming language. In my experience it’s really good in situations where the person creating the app is a statistician or person who’s background is processing data with R but may not have a background in web development. R Shiny allows those users to build pleasant user interfaces within the R programing model without the need to learn a bunch of new web technologies or have full stake developer skills.
What it lacks is the robustness and freedom that comes with modern web frameworks with tools like React, Angular, jQuery and regular vanilla JavaScript apps. When you’re building a website in R Shiny you have to follow the patterns and practices of R and Shiny – I suppose you could argue the same is true for any application you’re building no matter what the tech stack might be. To some degree you’re having to play within the boundary of your chosen technology stack. However, it’s my opinion that you get more freedom when breaking away from R Shiny and building your websites in something like React for instance. I choose React because that is my front end framework of choice.
Here are a couple of different ways I’ve been successful migrating from pure R Shiny websites to a modern web frameworks like React. But in order to pull off any of the following options, you’ll need to have full stack experience working with front end layers, API layers and the database layer. This can be a single team member or an entire team.
Distributed Option
I like to break R Shiny apps into distributed parts consisting of a web front end and side car process. The side car process is the original R code that produces either .CSV files or dumps the results of the R code right into the database. The web framework delivers the data to the end user that was creating by the R code process.
Starting with a process where the R programmers continue to develop their programs using R but instead returning the data directly to the R Shiny app, I set up a SQL database to house the results of the R code. Like I mentioned, this process can either be a .CSV file that is then imported into a database or the R code can populate the database right from the program. Then a React front end will connect to a .Net WebAPI built in C# which retrieves data from SQL Server or other popular database system like MySQL or PostgreSQL.
This is a nice way to break things apart to give companies greater flexibility in their systems. By allowing React or Angular or Vue the organization has unlimited possibility in what they can do with their data. Integrations with an API, HighCharts, Mapbox or custom dashboards are simplified with this route. This also allows employees to focus on their specialty, be it writing R code or custom websites. In environments where a statistician is really good at producing rows of processed data, a web developer can easily grab the results and make them available on the web. Neither the statistician or the web developer need to spend time getting up to speed on a new technology.
SQL Server Option
Starting in SQL Server 2016, you can write R code in SQL Server using SQL Server Machine Learning Services. In short, it SQL MLS allows you to run R or Python code on your SQL Server and interact with your relational data right at the database level.
Machine Learning Services is a feature in SQL Server that gives the ability to run Python and R scripts with relational data. You can use open-source packages and frameworks, and the Microsoft Python and R packages, for predictive analytics and machine learning. The scripts are executed in-database without moving data outside SQL Server or over the network. This article explains the basics of SQL Server Machine Learning Services and how to get started.
Setting up SQL Server MLS is not complicated but can be somewhat complex. There are a few moving pieces that need to be put into place before you can start running with this option. You’ll need administrator server rights to the SQL Server(s) in order to install the MLS package to start. With the SQL Server option you can keep all the R scripts that were originally running inside R Shiny and migrate them to SQL Server.
Once SQL Machine Learning Services is set up on the SQL Server it’s just a matter of setting up the R script and query combination. You execute the R code via a SQL Server stored procedure with a relational data set input parameter and the R code to run. You don’t need to pass in the data set input parameter if your R code is not going to be processing any data. However, you get the most out of this integration if you processing data with R – otherwise using the SQL Server option can be a lot of overhead that’s not needed.
This architecture set up follows the standard web client –> API –> database model with the simple addition of Machine Learning Services. Machine Learning Services are a combination of separate executables that run on the SQL Server. The first is either R or Python and the other is a service which handles communication between SQL Server and the R/Python process running on the server. This is a flowchart diagram of how the process works from the moment the user kicks off the process the web client sends a request with some query parameters. Perhaps the type of process to run along with other variables. The API translates that request into a SQL Server request to run, the SQL Server takes that request to execute a MLS process which process the R script against any data set that is passed from SQL Server to the MLS process. Once the R processing is complete, MLS returns a data set back to SQL Server which can be further processed by additional queries or returned to the calling API. The API then returns a payload to the web browser to display to the user.
Conclusion
These are the two methods that I’ve used to help clients move from R Shiny to a React or other SPA web framework. In the end this architecture gives companies more flexibility for developing interactive websites or reports that rely on R to do hard core data analysis. By breaking the architecture into these other technologies you’re able to spread the work out throughout the team and allow the developers to do what they do best. The R programmers can focus on R and the web developers can focus on the web side of the application.
If you need help to migrate your apps from R Shiny to React, Angular or Vue I’d be more than happy to help. Just reach out via the form on my contact page.
I’ve been working through Brennan Dunn’s Double Your Freelancing email course to level up on my technology consulting knowledge. This helps me learn what’s been successful for other consultants in the technology world so I can apply new things to my own business. One of the topics Brennan covers is for you to think about the first time you ever had to attach a price to yourself as a freelance developer. A big takeaway from the first couple lessons is don’t under price yourself as a freelance developer when pitching yourself to potential clients.
I want you to think about the first time you ever had to attach a price to yourself as a freelance developer.
– Brennan Dunn
There are two glaring instances that come to mind when I think about the first time I attached a price to myself as freelance developer. Both of those instances I set my freelance rate extremely low in order to win the projects. Both times I failed – either I didn’t get the project because my rate was so low or I did get the project but because I didn’t accurately scope the project the result was sub-par for the client. Back when I was a green freelancer developer/consultant I would do anything to get those first portfolio pieces. But over the years I’ve learned a lot from those mistakes and now both my clients and I are better off because of what I learned from those mistakes.
Bad Product
My first freelance web development project was a side project while still working as a full time developer. Landing the gig was a lot easier than I thought landing my first freelance gig would be. I set up a Twitter search query to return results for anyone looking for a developer near Minneapolis. You can do this using the near operator followed by your search term. For me this query looked like: near:minneapolis “looking for a developer”. I responded to one of those tweets, met with the client, reviewed what needed to be done and threw out a price. I don’t remember much conversation but I was awarded the project right away. It was almost too easy.
The project was a simple CRUD application for a home goods supplier. Since I had no experience in the freelance market and I didn’t want to lose out on the job, I massively underbid the project. I think my bid was like $3,600 for what I’d quote today around $20,000. It was insane. I ended up working for free on a lot of the project and and ended up delivering a sub par product because of that. Since I massively underbid the project and was new to this world, I wasn’t comfortable doing the right thing – going back to the client to explain my shortsighted bid and to renegotiate the project cost. Instead, I worked fast and didn’t’ deliver the exceptional product that I had promised the client.
Too Cheap
The other time I remember pricing myself so low was when I was asked to submit a bid to redesign a client’s website. During the proposal process they asked to see my portfolio of other projects I’d done. Since I was just starting as a freelance developer I didn’t have any paid client work to show off. All my development up until this point was confidential or internal to my previous full time jobs. Even though I didn’t have a portfolio to show, the client still met with me and asked that I submit a proposal. I thought this was a good time to undercut any competitors while creating a simple website design that I could start to use as a portfolio piece. The idea was to bid extremely low and work a little bit for free to get this portfolio piece. So I wouldn’t really be working for free as I’d be getting a portfolio piece in exchange for work done. Ah, kids…
I submitted my bid at $3,000 – I guess $3,000 was my benchmark in those days. Needless to say I did not get the job. But the kicker in this story is that a while later I got an email from the head of an agency who had also submitted a bid for the same project. In the email the person asked me “did you really bid that low on this project?”. Turns out that my bid was so low that the client brought this up to a competitor just to see if it was real. They didn’t believe my bid was serious because it was so low, in fact it was a good $15,000 lower than the agency bid. So you can be too cheap and it turns out a race to the bottom is not a race you want to be in.
What I learned
Fast forward to today, I now look back at what I did wrong and apply the knowledge I learned from these experiences to all projects I work on. Before any lines of code are written or any costs are submitted I sit down with the client to discuss the project in depth. I call this phase the discovery phase. During the discovery phase I will take deep dive into the reason why the client is hiring me in the first place. I want to understand the why and what behind the project:
Why is this client looking to hire someone like me?
What problem are they trying to solve?
How can I help them achieve their goals?
What does a successful project look like?
After we’ve answered the questions above, I should have a pretty good understanding of what needs to be done. The discovery phase allows me to get a good understanding of the problem so I can then be in a position to submit a well informed – and accurate – proposal.
Conclusion
In the end I made a lot of mistakes when I started out as a freelance developer, but one of the biggest ones that hurt me the most was under pricing myself. Not only did I not get jobs because I was so cheap, but I didn’t deliver the quality applications I pride myself in.
You see, most of the time our jobs as consultants shouldn’t be to just write code (sometimes that actually is the case) but the majority of the time it’s to help solve a problem or even uncover a problem. All of that comes down to helping clients be more successful in what they do. Today I spend a lot of time thinking about the client, determining what they need versus what they want, and listening to their problems and pain points before I even start thinking about hours and numbers. This has helped me not only become better at my job, but I’m consistently delivering more value to my clients. Which is the entire point anyway.
