Between the three of them, the co-founders of Orbit have decades of experience in engineering and developer relations, building products at companies such as Accenture, Algolia, Apple and Keen.io. After launching Orbit, they spent the last year talking with people in the DevRel space about proving the value of DevRel.

January is a common time for executives to ask what kind of investments they should make in developer relations including what hires to make, and what the business case is.

After Orbit joined Heavybit last month, I sat down with Josh, Patrick, and Dustin to talk about their approach to DevRel, from partnerships and promotions to outsourcing and metrics.

Table of Contents

• What are the biggest missteps companies make when it comes to DevRel?
• What parts of DevRel should companies outsource?
• How do you leverage partnerships?
• How can DevRel partner with business development?
• How do you balance creation vs promotion?
• Who in DevRel would you like to call out?

Q: What are the biggest missteps companies make when it comes to DevRel?

One big mistake is trying to hire a developer advocate before the company has learned to do at least a little DevRel on their own. In the consulting world, companies would come to us and say "we’re ready to hire, we just need help writing a job description and sourcing candidates." At that point, sometimes these companies had not given a talk or created developer-facing content.

By contrast, at some companies, every engineer is doing some aspect of DevRel from the time the company starts, like giving talks and contributing to projects. If a company tries to hire a DevRel-specific role but doesn’t have experience in that area, it’s going to be difficult for them to be successful.

Companies and teams have to define their internal expectations for DevRel. It’s common to read a job description for DevRel that isn't focused -- it could span dozens of key activities! If a company has done DevRel themselves, they typically surface a more focused job description. For example, do they see this role on the road giving talks, or being an internal advocate? We want to help companies avoid writing job descriptions that are “be all the things.”

Q: What parts of DevRel should companies keep in-house, versus outsourcing?

It depends on which parts of the DevRel process you need help with.

On one hand, your DevRel person who has the touch points with the community -- that person should live and breathe inside your organization and embodies the organization's culture. If a company has contracted with an outside firm, you may not get the same experience talking to them, versus talking with employees embedded in the culture of the company.

If your advocate echoes your values, it leads to a better developer experience. That’s a risk when making a contract hire, especially on the community side. I’ve seen contractors do social media for a company’s developer community and it all goes wrong — it’s mind blowing why companies do this with little training and oversight.

However, if you’re working solely on content, tutorials, etc, that can be a great place for outside help, since there will be other people in the organization that are reviewing the content to make sure it falls in line with the company's positioning and values.

We consulted for the past year so we have some bias here, but using outside companies to generate strategic, third-party content can give you a lot of leverage. They can lean on your internal teams to amplify the content and bring the messages to market. We’ve done this a number of times with different companies -- it makes developer advocates inside the company feel like superheroes because they have a lot of great content that they can bring out and share with the community.

Q: How can we in developer relations leverage internal partnerships to increase our reach and effectiveness?

We think partnerships can be one of the most impactful parts of a successful DevRel strategy. A single advocate or DevRel team serves as a force multiplier across the entire company. The internal impacts of a team that’s working well are enormous when multiplied across the entire company.

We can give tons of examples, but to focus on a few: in marketing, DevRel can help keep the brand voice true to the developer personality. In return, marketing helps DevRel be more data driven, driving value in both directions.

In larger companies, there is an opportunity to bring the voice of the developer into internal conversations. You can imagine bringing stories from the field into the walls of the building and giving the company a few into how developers interact with your product.

Historically there has been somewhat of a mismatch between teams like sales and marketing and community teams like DevRel. Often this is based on a mismatch in funnels.

DevRel can evangelize alternate models of measuring impact of community instead of the standard model of pushing people into a funnel and measuring purchasing events. The Orbit model allows you to rewire the way companies think about community, not just a standard marketing funnel, but allowing you to create metrics around your community efforts.

We also see DevRel and Sales working well together — historically, this isn’t always the case! We've seen that they can be very collaborative and complementary when there is clear communication.

In large organizations it's rad to see individual developers participating in the community -- if a company's developers are contributing to your project, that’s a strong signal that the company may be interested in a commercial relationship.

From a sales perspective, you probably don't want an SDR emailing those developers, but the SDR would love to have feedback about that developer’s activity that they could reference when calling the developer’s manager. Of course, that requires data and tooling on the back-end to surface that information, and that’s something we see a lot of companies moving towards in 2020.

We actually wrote a whole series for Heavybit covering different tactics for internal collaboration.

Q: How about business development -- where are the opportunities for developer relations teams to partner there?

Agency partnerships come to mind pretty quickly. For companies with a developer-focused platform, part of the BizDev model is to partner with agencies who can build the platform into products for clients. Algolia had relationships with agencies implementing all the different ecommerce and CMS platforms.

Creating formal partnerships with these companies can be useful for BizDev but can also help your DevRel program by encouraging the agency developers to be involved in the technology ecosystem.

DevRel can also partner with complementary companies and projects. This can keep things fresh and make sure you’re not talking too much about yourself and your products -- you're bringing some fresh voices into the conversation.

Q: Where do you draw the line on creating new assets, such as content and talks, and promoting those assets? Should 100% of your DevRel budget go to creation, 100% to publicity, or somewhere in between?

Looking at DevRel as a whole, generally we think that more re-use would be smart. Writing a new presentation each time you give a talk is very expensive in terms of effort and mental energy.

Many developer advocates are hesitant to re-use material, but they shouldn’t be -- there are millions of developers out there who haven’t seen your presentation before. If stand-up comedians can re-use the same jokes for years, you shouldn’t have to worry about giving the same talk twice in the same city.

One trick I have: give talks to engineers inside the company, and then let the engineers give that talk elsewhere. Make your assets and presentations so that others can re-use the deck and script. That’s a nice way to get engagement in the DevRel effort from others in the organization — three months later, someone is speaking on stage, maybe for the first time.

Often there are engineers inside your company who want to get started getting talks, and as developer advocates who do this multiple times per week, we can facilitate these engineers and also cover more territory. (There are a lot of events I want to speak at, but I can’t be in two places at the same time.)

Q: Is there anybody out there in DevRel who is doing an amazing job, that you’d like to highlight?

• Doron Sherman, VP DevRel at Cloudinary has a great DevRel program
• Stefan Judis at Twilio for being data-driven, he’s got a great approach and dashboard for his content that is pretty impressive
• Tim Berglund and Ale Murray, Confluent team

Thanks to Josh Dzielak, Patrick Woods, and Dustin Larimer for chatting with me about their DevRel experience.

Next Steps:

• Follow Orbit on Twitter
• Check out (literally, you can check it out) the Orbit Model GitHub repo
• Catch up with Orbit's DevRel Blog.

Pricing can be the life or death of a bootstrapped startup.

When I started the process of trying to price my startup I became overwhelmed with questions and doubts. Should we have usage-based or a tiered pricing model? How much storage can we offer at each tier? Should we offer a free plan? What should the base price be? What if no one wants to pay for this? What if Tueri is a failure?

I have spent countless hours trying to answer these questions and pricing has been the single most daunting part of launching Tueri. Tueri is a completely bootstrapped startup and ultimately, pricing can be the life or death of it. Investor money is non-existent, meaning the company needs to be profitable at every stage of growth.

It boils down to these two essential questions:

1. Can I provide exceptional value and service to my customers at this price?
2. At this price, can Tueri continue to grow and be on the leading-edge so I can continue to deliver exceptional value and service?

These two questions may seem at odds, but they are essential for building a long-term, customer-centric company.

What is Tueri?

The word Tueri is a Latin word that means: preserve. Tueri is an image management and optimization platform based on the idea of an immutable master image.

Tueri uses just-in-time image transformation, compression and conversion to deliver the perfect image to each one of your users in just milliseconds.

The idea for Tueri came during my work as an application developer. As a developer, I build customer-incentive applications for automotive parts companies. The basic premise for these sites is the more auto parts a customer (mechanic shop) buys, the more points they earn. Customers redeem points online for everything from golf clubs to TVs to vacations.

These websites receive daily file feeds from vendors with new, discontinued, and updated products. There are thousands of products and no standardization on image dimensions, file sizes or image hosting HTTP protocol. I built Tueri to solve these problems.

The first version of Tueri was a simple proxy server designed to fetch remote HTTP images and re-serve them over HTTPS, removing insecure-content warnings on our customer-incentive sites.

The next version was a simple one-page PHP script using GraphicsMagick. This script fetched a remote image, resized the image if it was over a predefined width, stored it on the server and served the image over HTTPS.

These iterations soon progressed in scope and features and somewhere along the way, I realized it was saving me obscene amounts of time.

I needed to share this with other developers.

After a lot of work converting a personal project into something I could host for others, I was ready to launch. The only problem was, I had no idea how to price it.

Should we offer a free plan?

Here are some reasons why a free plan makes sense:

• User Acquisition — Offering a free plan can help you acquire a ton of new users. This, in turn, should drive growth through word of mouth marketing.
• Upselling — A user on the free plan can be upsold to a paid plan.
• Supporting the Community — In my jobs as a developer, I have relied on countless free services and have benefited greatly from the open-source community.

My fear of not offering a free plan was that I would have a very hard time acquiring new users. I struggled with this question what seemed like hundreds of times, so I did some research.

I researched countless other startups. I wanted to know whether they offered a free plan, what features they included, what percentage of users were on it and if they were profitable.

I discovered the following:

• Free users will drive growth through word of mouth, but they will drive more free plan growth.
• A free plan will help you acquire more users, but only a very small percentage of those users will ever convert to a paid plan.
• A huge percentage of support is dedicated to free users.
• A free plan product is often inferior due to costs associated with back-end services.
• This inferior product is the product that people come to know your business by.

The Free Plan Decision

I have decided not to offer a free plan in order to dedicate 100% of our resources to our paying customers. This ensures both the quality of the product and exceptional customer service.

Should we have a usage-based or tiered pricing model?

Usage-Based Pricing

Pros:

• Only pay for what you use.
• Better for companies with seasonal usage fluctuations.
• Better for individual developers where low monthly spend is a priority.

Cons:

• Difficult to understand what your actual monthly bill will be.
• Potentially drastic monthly bill fluctuations.
• Harder for a developer to pitch to their company.
• Customer mentality is focused on limiting usage to keep costs down, thus decreasing the perceived value of the product.

Tiered Pricing

Pros:

• Easy to understand your monthly bill.
• No monthly bill fluctuations.
• A fixed monthly amount is an easy pitch for a developer to make to their company.
• Customer mentality is focused on getting the most value out of their plan, thus increasing the perceived value of the product.

Cons:

• Harder to appeal to all use cases.
• Not as ideal for seasonal use customers.
• Hard to appeal to individual developers with a minimal budget.

I scoured hundreds of pricing pages from different Software as a Service (Saas) companies; some simple, some complex. I continually gravitated toward tiered pricing models based on the fact that they were easier to understand. Many companies with usage-based pricing dedicate an entire page to explaining how to calculate your monthly bill. Even after following the examples I still could not say for certain what they would cost me.

Let's talk about an example of usage-based pricing for Tueri. Let's say its priced per image transformation. You have a simple responsive website with 10 pages and 10 images per page for a total of 100 images. You check Google Analytics for device usage: you have one desktop resolution, one laptop resolution, two tablet resolutions (portrait and landscape) and two mobile resolutions (portrait & landscape). If every image on every page gets viewed ten times by each resolution you have a total of 6,000 transformations.

Easy right? Not exactly.

In reality, you may have 10,000, 50,000, 100,000 or more page views a month. You could have 20+ different resolutions, HiDPI displays, pages with varying levels of views, and new images added regularly.

You can see how this gets complicated.

The Pricing Model Decision

While it was not an easy decision to make, I concluded that tiered pricing was right for Tueri due to its transparency and simplicity.

What should the base price be?

This has to be the single most difficult question to answer, at least it was for me. One that I will continue to ask and re-evaluate throughout the lifetime of Tueri.

I had to assess:

• Are we a premium or a value company?
• What type of users do we want to focus our service on?
• Do we want to serve millions of customers at a low price or thousands of customers at a higher price?
• Can we continue to provide exceptional service to our customers at this price?
• What is the time value we are providing to our customers?
• What is the monetary value we are providing to our customers?
• What does our competition charge, are they profitable, and is their business sustainable?

It boils down to defining priorities:

• I want to provide an exceptional level of service to fewer customers.
• I am in this for the long-haul and our pricing needs to be sustainable.

The Base Price Decision

Pricing should not be static, you should assess it over time based on feedback from customers, the added value from new features, and operating costs.

We are constantly evaluating our pricing and I would love to know your use case and if our pricing works for you.

Conclusion

I finally realized that I was never going to have it all figured out, so I made the best decisions I could with the available information and launched.

There is no definitive answer to pricing your startup, but keep these things in mind and you won't go wrong:

• Exceed your customer's expectations in the service and value you provide.
• Price your business for growth.
• Launch your startup.
• Reevaluate your pricing continually.

Do you have any tips or questions about pricing your startup? Get in touch at dane.stevens@tueri.io.

_Originally published at Tueri.io_

This series portrays my experience as an R&D group leader of a group that has the same behavior as a failing startup. In my last two blog posts, I’ve presented a short background regarding the developers and the technologies. This blog post will deal with the vague definition of a group’s identity.

In my last blog post, I portrayed an image almost too good to be true. An image of a productive software group, full of energy and hunger for projects. I knew I must look away from newly gained success and only into the problems, however unfortunate that made me feel.

On the one hand, I felt the need to present the milestones I’ve created to restore some kind of productivity. I wanted to show the boss all the recent successes — the coding methodology, working regulations and other concepts we’ve begun implementing. I wanted to present the training concepts and procedures we’ve established. I wanted to present the strong cooperation I’ve led with another organization. This cooperation granted an opportunity to combine the organization’s knowledge pool and create better professional training for my group. On top of these, one of our projects was accepted to an acceleration program. I really wanted to show that off as well.

But I knew this image would soon fade unless I continued targeting the main issues. The primary issue was this next hard truth. The group didn’t have a strong basis and it was just a matter of time until it might collapse again. I identified it as the group’s lost identity.

What is a group identity?

When we reach a point in life where we seek our unique identity we look into various questions. Where am I from? What is my heritage? Who influences me? What’s exciting for me? What’s the reason I wake up in the morning? These questions helped me shape my personal identity both as a human being and as a leader. The same process happens one way or another in every organizational structure.

Defining a group’s identity must happen the moment a manager takes the reins. They must look at the group’s responsibilities and define each group member’s position. It clears many things up. It provides clear borders regarding the manager’s and the developers’ responsibilities.

This process must occur at the group manager’s level and even higher. It is rare that a complex organizational understanding such as an identity can depend on the team leads’ scope or lower. It is also unfair to the team leads, who already have enough on their plate.

As you may recall from my previous blog post, I talked about the vicious zero-products cycle. This cycle started somewhere, so I started retracing the group’s steps. I realized that the moment the last official product version was released was the breaking point. This was the point where there was no clear view on what the group’s main objective was, what was its purpose and what was the product it was responsible for delivering.

What was the main objective?

The main objective was software and system maintenance for a very complex system. In order to perform software maintenance on such a large amount of code, a developer must work on the code. The developer must understand it and get to know its genius functions, but also its inherent faults and flaws. The developer must feel the code. They can only gain this feeling through massive research and deep understanding of procedures within the system.

In my view, it is impossible to maintain the entire system simultaneously, as a result of a small number of maintenance dedicated developers and a very serious lack of knowledge. So I declared that maintaining specific domains every year was good enough for us. The alternative would be scattered maintenance that would only lead to more gaps in the long run.

Let’s look at a simple example such as inserting an image on a screen. This is easy in modern systems written in readable code that follows proper coding methodologies.

In our case, to insert a feature, the developer needed to follow more complex steps. They would research the entire screen’s code and the entire code of screens that might be affected by the change. It might take up to a month of research. After the research would’ve developed some conclusions. They would try to decipher the relevant piece of the system’s architecture and find a few ways to implement image insertion.

In parallel, and this is the important part, the developer must document EVERYTHING. Every difficult method. Every process they discover. Every architecture or network insight they have. Every unusual phenomenon and its investigation all the way to its origin. This is crucial since the existing documentation and most of the written code are barely readable.

The objective seems very straightforward, but regulated documentation and code maintenance is not the only thing that defines a group’s identity. The group has to have a purpose. Our purpose went missing.

Where did the purpose go?

At some point, software maintenance was performed under no regulations and slowly went out of the professional focus. What started flowing instead were side projects. Side projects became the main objective. Whenever a client approached one of the teams, in need of a quick fix, the group would pivot in that direction. People were working on side projects for the sake of working. The difficult yet crucial maintenance was completely abandoned.

When I started my position as group leader, almost every group member told me they didn’t know exactly what the group was actually meant to do. They felt they had no real goals when they came to work. Side projects scattered the purpose.

Why do we sometimes need to manage our clients?

A software group cannot blindly do what the client wants. Especially when the client changes their mind frequently. For example — back when I was a software developer, my team and I were working on a navigation project similar to “Waze”. Our product owner kept requesting changes that made no difference whatsoever to the system’s functionality. It was always a request to change button colors or move toolbars around the UI. This kept the team from making any progress for a very long time.

In my software group, the problem was on a larger scale. The group didn’t have one indecisive client. It had a few separate clients and each client pulled in their own direction. There wasn’t one integrating factor, looking at the larger picture and managing the clients and the projects. For a long time, the group worked through a queue — first client in meant first project the group developed. Therefore, almost any type of project could be brought to the group. In time the group began dealing with QA, IT and even hardware issues, rather than software development.

Retrieving the purpose, and consequently the motivation, was an ongoing process. It began with a definition — I’ve defined, along with my team leads, our projects. We’ve prioritized them in accord with our clients’ demands, thus setting a roadmap we will not slip from, as happened in the past. This roadmap indicated our objective — system’s software maintenance was declared our purpose.

We’ve added one more project to the roadmap, a second main project, related to the system but not directly. It added to the purpose since it had great unimplemented potential. I believed it would be great for PR and to enhance the developers’ belief in their own skills. This dedicated roadmap focused the teams. We knew that by the end of the year we needed to deliver two products end-to-end.

Setting the professional compass was important. The bigger problem was regaining the developers’ trust in the group. After so many years, my developers — both experienced and new — had no fuel nor will to work. After some of my scheduled one on one talks, I mapped each developer’s strengths. If for example, one developer was really good at research — I let them do the research.

After mapping individual strengths, I mapped team strengths. Some paired programming was performed in order to strengthen some developer’s self-esteem. We’ve held a professional workshop for team leads, to strengthen management abilities. I addressed the issues I picked up when I observed the programming process and the issues the developers themselves had presented.

So how was the identity restored?

By finding a definition and restoring order. We’ve defined our field of expertise. I’ve put borders around our designated projects and let no other project cross that border. Limited the issues we work on (no more hardware issues!). Made sure there was proper usage of coding methodologies and version control. Made everyone document their work. Strengthened each programmer’s strengths. Sharpened the team leads’ set of soft skills.

I targeted both professional and personal values in order to restore the group’s inevitable software DNA.

The difficulties of leading changes in an unforgiving environment, leading innovation instead of sinking and how to survive as a young female in a very ego driven male environment? Stay tuned, all this and more as the series unravels!

Part 1 — How Can Corporations Heal a Dying Software Group?

Part 2 — Overcoming a Technological Gap — a Horrible Circumstance or a Creative Adventure?

Parts 1+2 — How I started the process of healing a dying software group

In less than one year, I went from a Georgia Tech Coding Bootcamp graduate to a business owner specializing in web development of business websites. There are several challenges I’ve faced and continue to face during the process. These range from networking to contract creation and pricing to, most importantly, having the essential trait of plain ol’ grit.

If you are reading this article, you are probably interested in the idea of owning your own business. No matter your background or level of experience you may have in the field, many of these hurdles will apply to you as you embark on the crazy, yet fulfilling journey.

My Background

Before entering the bootcamp in January 2017, I had very basic knowledge of HTML, CSS, and JavaScript — not even enough to make an entire webpage that was worthwhile. However, I already knew I had a passion that I needed to uncover and explore, and so my journey began.

At the beginning of the bootcamp, if someone had told me that I would have my own web development business within a year of graduation, I would have laughed them out of the room. I had spent literally hours and hours on our basic HTML/CSS/Bootstrap assignment alone!

The finish line of graduation was no where in sight, and the pressure was on…but I made it! I had learned a crazy amount of technical web development skills in those six months. But the most important thing it taught me was how far I was able to push myself to get what I had been dreaming of and actually accomplish it. This was the start to a new me.

I graduated the Georgia Tech Coding Bootcamp in July of 2017 with a job offer from one of the top telecommunication companies in the country within one week, and signed my first freelance contract in October 2017. Things were happening quickly and it didn’t slow down.

Keep reading to discover some of my networking techniques, advice, and to find out what the heck I did once I started getting clients. I’ll give you a hint — at first, I had no idea.

Networking my way to success

I had my first potential client lined up in February 2017, one month after bootcamp started. I met the business owner through mutual connections, and the conversation organically developed as the business owner vented about their frustrating experience with their current website and web developer. I jumped in.

At the time, I was still terrified, and I still didn’t know how to build a complete website (far from it). I was nowhere near ready. However, when an opportunity presents itself, I always tend to seize it and figure it out along the way.

I explained my schooling, my current timeline, and offered to develop a more attractive and more efficient website that they could be confident in and proud of. They were excited about the idea, and I was fortunate enough that they waited until my graduation in July for me to start on their site.

This was the start to developing my freelancing business.

I signed the contract for this project in October 2017, and completed the project in January 2018 with an ongoing hosting and maintenance contract. They were extremely pleased with the website, and have since stated that they intend to refer any work they know of to me.

As soon as that project was wrapping up, I got a message on LinkedIn from a startup owner looking for an independent contractor for some mobile development work. Thanks to my personality and hunger for growth in my new field of expertise, I signed a new contract as a part-time independent contractor in February of 2018. I agreed to 10+ hours a week, since I was still working full-time as a full-stack developer.

Just after signing this contract, I was approached by yet another company to develop their business website. Even with my busy schedule, I agreed to take on developing their site as well. To be fair to the company, I was transparent with my current schedule, and we agreed on an acceptable timeline and a contract was signed.

As business was consistent and even picking up with potential clients in sight for the future, I decided that it was finally time to start my own LLC. One big reason for this step was the obvious tax benefits — I could finally receive tax breaks and also be taxed fairly on the work I was doing. That’s great and beneficial, but the main reason was that I was finally able to fulfill my dream of owning my own business.

Currently, I am working full-time for someone else and part-time for myself, but the ultimate end goal is to work for myself 100%. This was the first step towards accomplishing that.

Networking tools I use

LinkedIn

• Make sure you have a good, professional photo.
• Update your profile and maintain it so it is always up to date — this is your living resume.
• Customize it so that your profile stands out from others. That may be a different background photo, or an eye-catching ‘about me’. Be creative.
• Stay active. Like and post relevant content daily. Your consistent activity will be visible to potential clients, employers, and recruiters.
• As messages start rolling in about jobs and opportunities, even if you are not interested and it might be overwhelming, always respond back professionally, respectfully, and thoughtfully. In the future, you never know when that individual may have a key to the locked door you’re trying to push through.
• If you have fellow developers who would fit the bill, recommend them. The recruiter will appreciate it and so will your peers. You never know when a peer might be the one to open a door for you either. (Plus you could get a referral kickback if it works out.)

Business cards

This method is almost outdated now in a world of technology, but it still has its merit. I always carry cards on me and have often found myself handing them out at any gatherings, meetings, and meet-ups. Sometimes I even pin them up on boards like in a local coffee shop. You never know who is looking.

Never be the person scrambling for a piece of paper when someone asks for your information.

Be kind — because word of mouth matters

To me, this one should be a no-brainer as it pertains to any aspect of personal and professional life: be kind. Word of mouth goes a long way, and honestly will probably get you most of your projects from referrals.

If you are known to be kind, consistent, positive, communicative, and honest, you are more likely to gain work. Professionals will trust the opinion of another professional over the opinion you present of yourself. If they receive positive feedback of an experience with you, you’ve got yourself another project.

Find a mentor

Let’s be honest. You most likely don’t have all the knowledge and experience it takes to start your own business. That’s why it is so important that you find a mentor or two…or ten.

It can be intimidating getting out there and extending your vulnerabilities to someone whom you may or may not know very well. But once you get over the hurdle of pride and stubbornness, you’ll enter a world of professionals who are more than willing to assist you along your journey.

Everyone needs to start somewhere, and most (if not all) started right where you are at this very moment — reading articles about how to make a dream manifest in your mind, and how to bring to life a skill at your fingertips.

One of my key mentors is one of my bootcamp instructors, John McSwain. He is incredibly passionate about coding, knowledge, teaching, and life in general. He is an inspiration in bringing dreams, thoughts, and ideas to life. He is also a big proponent of the key ingredient of grit.

Several times throughout the bootcamp when students were becoming discouraged with the amount of work, the difficulty, or time management, he would give the best back-to-reality talk to pick you up and get your stuff together. I needed his wakeup calls, and he was the first one I went to when I was thinking about diving into the freelance world.

I already knew I had my first client lined up, but I was terrified and my confidence wasn’t where I thought it should be. When everyone else I had talked to said that freelancing was “not a world to get into,” or it was “too tough,” John’s response was, “Go for it!” And I did.

Don’t be afraid to ask questions

Starting a business is also intimidating in the financial and tax categories. I actually came across a freeCodeCamp article and video on my LinkedIn feed by Luke Cicilieno. He was able to answer a lot of the questions I had in my head, which was the last step that was holding me back from jumping into all the paperwork and glory that came with the job. During his video, Luke encouraged viewers to “feel free to contact him with any questions”… and that’s exactly what I did.

I found him on LinkedIn, sent him a message to see if he was willing to answer any questions, and he did more than expected. He responded promptly and offered to hop on the phone with me to discuss any questions I had. This ultimately gave me the final push I needed to get the paperwork going.

As I said before about networking — you’ll be surprised to see how many professionals are willing to stick out a helping hand and offer advice, support, and even potential referrals! Ask questions — the worst that can happen is that they don’t respond, or say “no.” Feel free to reach out to me as well!

Ok, I have the client — now what?

The story of my first client

This step was one of the most challenging for me to overcome. I did the work to gain the skills, I did the work to network and gain the client, and now they actually want to hire me… now what?!

I had never created a contract before, I had no idea what I should charge, and putting a project timeline and deadline together seemed daunting. Just like you, I started out by reading several articles about all the different aspects of the business side of freelancing.

Things I knew I needed to figure out

• Price
• Payment plan
• Content
• Timeline
• Deliverables
• Contract

A sit-down with the client to discuss desired content is of utmost importance. This is what drives the price, timeline, and deliverables. Before that meeting, I sent the client a list of 10 simple questions to answer about their website, business, and vision. This gave me a good idea of what exactly they were looking for, what was most important to them. I also hoped that their answers would help fill in some other blanks, too.

Here’s my little questionnaire:

1. Tell me about your business. What does it do? What does it provide? What is your philosophy?

2. What would you like your site to accomplish?

3. What makes your company unique and remarkable?

4. Who are your competitors?

5. What types of websites do you like? Why do you like them? What types don’t you like and why?

6. Who exactly are your customers? What audience would you like to reach?

7. What features would you like your website to have? Social media connection? E-Commerce (merchandise shopping)? A blog? Photo Gallery? Videos? Mobile app or responsive? Contact/Feedback form?

8. Do you have any existing design material? Logo? Old website? Promotional items? Something else?

9. What is your budget for this website?

10. What is your timeline for launching this website?

Once I received the answers, I set up a face-to-face kickoff where we could go through the answers, discuss them, and come up with some reasonable guidelines and stopping points for current desired content.

Setting a timeline

The content was listed and described as specifically as possible so there were no questions or miscommunications about agreed upon items such as pages, colors, and functionality. Once this was done, we were able to move onto the timeline. The agreed upon content, my availability, and the clients desired timeline all played a role in this.

Luckily, the client was not in a hurry, so I was able to set the timeline based upon a reasonable commitment from myself based on the criteria. It is also important to note that creating the timeline is just as much on you, the developer, as it is on them, the client.

If they don’t get you the content, information, or feedback in a timely matter, the timeline pushes back. I made this clear verbally, as well as in the contract — which I will discuss in a bit. Along with the final launch date, we also decided on reasonable milestones a review process.

Every Tuesday evening, I would send my client my updates for them to review. I did this by launching the app on a free Heroku site so they could view it, click around, and make adequate notes on the current functionality and design. Their feedback was always due by Friday of that week, and if I received no feedback, I continued working as if it was a thumbs up.

This system seemed to work out very well and the client was very pleased with the level of transparency I was providing them.

Determining a price

Next, we needed to decide a price. Many articles went back and forth about whether to charge hourly vs. having a set fee for the entire project. Since I was brand new to the freelance world, and my client knew that, I decided that setting a overall lump cost for the project was the better way to go.

I already knew I would be putting in extra time since I didn’t have a project codebase or experience to lean on. I still had a lot to learn about the technologies I chose to use, and let’s be honest, I was still pretty slow. And I didn’t want my first client to pay for my learning curve.

We discussed pricing in person, and looking back it seems a bit like I low-balled myself. But that’s only because the amount of time I put into the project did not have the best return when breaking in down into an hourly earnings.

However, the price was agreed upon and I felt it was fair at the time for both of us. I needed to get my foot in the door, and they were willing to take a chance on a complete noob.

If this went well, I would have my first project on my portfolio and a satisfied customer willing to spread the word. Plus, I literally had no idea how much to charge or how many hours it would truly take me — trial and error.

Creating the contract

Once price, timeline, and content was discussed and agreed upon, it was now time to create my contract with the client. My first thought was, “How the heck do I write up a contract?” And “What the heck goes into a contract anyways?”

I was pretty lost, but I started researching and found this open-source contract for web professionals by Stuff & Nonsense. I took this contract and tweaked it a bit to make it my own. I wanted to make sure that the agreed upon price, payment, timeline, and content were all captured so there were no miscommunications or misunderstandings.

I also included the basic freelancing jargon of who owns what, who is responsible for what, and what the process is if something is not properly handled. After review from both parties, we signed the contract and the project was underway! Hooray!

Note: now that my business has been created, I intend on seeking out an attorney to create an official contract to use with future clients.

Grit

I left the most important part of my journey until the end: the importance of grit.

Grit is what got me through the bootcamp while working a full-time job with the late nights, early mornings, endless screen time, dramatic change in my social life (what social life?), the sacrifices of my relationships, time, money, sleep…

This is the same grit that allowed me to graduate with a certificate in Full Stack Development from Georgia Tech, earn a new full-time job at a top company as a full-stack developer, and have the courage and just enough insanity to also start my own company at the same time.

This is what will help you have grit:

• Be open to change, new technologies, criticism, failure, and success.
• Hold yourself accountable. No one will be there to tell you to work 8–5 or give you a story to complete. You need to create and complete your own stories and set your own hours. This sounds amazing, but can be incredibly difficult if you can’t hold yourself accountable.
• Plan, plan, plan. Use tools like Trello to track backlog, development, bugs, and reviews to keep track of your time and work.

If you share the dream of owning your own freelance web development company, expect it to be tough. Expect a drastic schedule shift. Expect a change in your social life. Expect a shift in your priorities. You are making yourself and your company a priority and change needs to occur to make room.

However, with all of the change, there are no regrets with only bigger plans in sight. It is absolutely astonishing what you are capable of when you find your passion, believe in yourself, and are driven to make your dreams a reality. That grit is your power.

Know that you CAN DO IT, all you need to do is JUMP!