Over the past few months, I have had the pleasure of working on a DApp called thisorthat.io built on the Ethereum network. It has been an absolute blast. I have had so much fun building the smart contracts as well as the React front-end interface.
I truly believe there is a huge future here, and it can be especially lucrative for developers/startup teams. If you look at Dapp Radar, you can see that many of the top DApps have less than 1,000 DAU (daily active users). If you consider how much money is being made, crypto-users end up being much more valuable than users on any other platform.
Take for example, Crypto Kitties. It's basically a mix of Beanie Babies and Tamagatchis. According to DApp Radar, 380 ETH (or $255K USD) has moved through their platform in the past 7 days with only 652 daily active users!!!. This is absolutely insane.
It's not all sunshine and rainbows though. After spending 80+ hours working on a crypto-centric app, I believe I have some insight into some pain points that will need to be solved before these types of apps are to be widely adopted.
In my next post, I will discuss some of the hurdles preventing DApps from going mainstream. There is so much room for improvement and innovation in this space, I feel that all devs should be looking at crypto like we looked at mobile dev in 2008.
To the moon!
tl;dr: micro.blog is pretty cool.
I have recently been thinking about my process of blogging / tweeting / facebooking / etc.. and have realized that I’m burnt out on all three. I LOVE to write. I started one of the first successful iOS Blogs, published numerous (software development books)[http://manning.com/trebitowski], and have been blogging since 2008. Here are a bit of thoughts about the various platforms and ultimately my solution.
Having over 4,000 followers on Twitter I used to find tremendous value in the platform. There was a time when I would ask a programming question and get 20+ responses within 10 minutes. I’m not sure if legit people have stopped following me or have stopped using the platform, but I am no longer getting any engagement. I probably have like 20 followers and 3,800 spam bots at this point.
To me, blogging has always had to be long-form. Maybe it’s just my wannabe Tim Ferris mindset, but this has held me back from writing for quite a long time. I would wait until I had a long (usually 1K words +) post before writing anything. So, it other words, perpetual writers block.
Don’t even get me started. I jumped on the #deleteFacebook bandwagon months ago.
Recently, I discovered Manton Reece’s new platform called http://micro.blog. I guess the platform isn’t necessarily new as he launched in 2015, but after using it, it still feels like it’s in the new/exciting phase.
Manton describes perfectly why he created the platform here and this captures my thoughts exactly on the content-creation ecosystem.
Here are some things that I’m super excited about the micro.blog platform:
- You post to your own site, keeping all the content controlled by you
- You can also pay $5 monthly for a hosted blog. This means their business is built on an actual product rather than advertising revenue.
- It’s built on RSS. I have always been a huge RSS fan and am glad to see a resurgence.
- It’s full of developers that I already know/admire. Guys like @manton, @collin, and @gruber.
- It’s incredibly social. The platform really encourages conversation.
- No follower count. This is arguably the best part. No one (including yourself) can see your follower count. This allows you the feeling to just create and not worry about the vanity of the whole thing.
I still plan on using Twitter to some extent, but my primary source of content publishing will/should be this blog. It will become a mix of my long-form posts and my “tweet-sized” snarky comments.
If this sounds even slightly interesting to you, def check it out and follow me on here or on micro.blog.
In 2008, I was still in college. I had just landed my first job with a small consultancy as their first iOS developer replacing their outsourced Ukrainian team. Within my first week on the job, the CEO asked me to jump on a sales call as the technical lead. This absolutely terrified me. I remember doing things like ensuring that I had a full glass of water so my throat wouldn’t get so dry (it still did). I also stumbled over my words, almost costing the team many sales. Eventually, I learned.
Since that day, I have taken hundreds of software sales calls. Each time trying to improve my process by testing out what works and what doesn’t. Now that I run my own company, I have found that one of the most beneficial things that I have done is implemented a standard call flow.
There is a reason that call centers require their employees to memorize call flows. When you have a call flow in place, it does a few things.
1. It allows you to practice and refine your pitch over and over again.
Practice makes perfect. Definitely cliche, but it makes a lot of sense here. As you give your pitch over and over again, you will start to pair it down to something that works for you and your team.
2. It builds confidence
Many people are nervous speaking to strangers. Software developers are no exception to this. As I mentioned above, I was terrified on my first few sales calls. This had a lot to do with the fact that I was ‘shooting from the hip’ and just trying to make things up as I went along.
Once I finally got a script in place, I was able to lean on it during future calls. This gave me the confidence that I was gathering all of the right information and representing myself in the best way possible.
Now when someone says “Could I see an example of your work?”, I can quickly shoot them a link or list rather than nervously trying to get the words out “well…uh…I made an app about catz, and I’ll find the link and…uhhh… send it to you later…”.
3. It’s so easy a ‘sales guy’ can do it
This is the part that I’m starting to experiment with. I want my pitch for my company to be so tight, that I could give it to any ‘sales guy’ to deliver and him represent Pixegon in much the same way I would. I have already done this with some of my engineers as I don’t always have time to make every single sales call and it has proven to be a huge success.
4. It removes emotion
This is a big one. When we are nervous, we tend to say dumb things. I remember a few times on sales calls when I was nervous (often because I really wanted/needed the contract), that I would seriously compromise on my rate just because the client suggested it. Had I had a call flow in font of me, I would have been better prepared to field such a request.
I now replace emotion with process and it usually ends up better for both parties.
Here is a rough outline of my sample call flow:
- Client Introduction - Ask the client about their background
- How did you find us? Good to find out what advertising channels are working
- Give my background - This is to establish credentials so they trust me
- Ask the client to give a 10,000’ overview of the project - Be careful here, they love to get in the weeds
- The 3 most important questions
- What’s your budget? This will let you know right away if you want to continue much further based on your budget tolerance and rough guess on how much the above will cost.
- What’s your timeline? Every single client will say ASAP. But really this is to find out if there are any conferences, holidays, etc… that are hard deadlines for them
- How are you funding this project? Self, Company, VC, Family, Startup, etc… This will also help you assess risk.
- Ask more detailed questions about the project (If timeline / budget are somewhat ok). Determine things like backend requirements, UI/UX, Staff aug vs full solution, etc…
- Don’t give them a $$$ estimate. They will usually ask you and it will usually cost you in the end if you give them a number here.
- If all goes well, ask them to send over any assets/wires/requirements and tell them you will follow up with a rough scope and estimate. Again, don’t estimate on this call
- Thank them for their time and let them know you will be in touch.
This is definitely a good starting point. Sometimes I will copy and paste these flows into a new document and tailor them based on the client that I am about to speak to.
Sales is something that I am constantly working on and refining. I hope to continue to share my findings with you as I learn along the way.
As developers, we hear the echo chamber on Hacker News and others shouting at us to raise our rates. We are worth it. In theory they are right, we are worth it and we should be charging an industry standard rate. However, there are some instances when it’s OK to lower your rates.
Here are 3 times when you should consider lowering your rates:
1. Building Your Portfolio
This is definitely the case when you are first starting out. If you don’t have a solid portfolio, why should a client trust you to build their project at full rate. You have no credibility and they would be better off using a large shop that charges the same rate, but has hundreds of apps under their belts.
Even if you are not just starting out, this can be a great strategy to employ if you are wanting to land a client that will “look good” in your portfolio. We have done this in the past when we have wanted to break into certain markets. We found some of the leaders in those markets, given them a killer deal (or built small projects for them) so that we were able to put their logo on our website.
This strategy has proven to be incredibly successful for Pixegon
2. Longer Term Engagements
Our overall goal is to make money and provide sustainability as indie software developers. If you get an opportunity for a longer engagement on a project you enjoy working on, this often times can be much more valuable than trying to get your full rate.
3 month gig at $125/hour VS 6 month gig at $100/hour
- 3 months * 172 hours * $125 = $64,500
- 6 months * 172 hours * $100 = $103,200
In my opinion, I would MUCH rather be working on a larger contract at a lower price than a shorter one at a higher price. At the end of the day, it’s all about the contract value and sustainabilty.
3. On The Job Training
As students of computer science, we should be able to build anything right? Well, sort of. In the past, there have been instances when clients have asked me to work in unfamiliar territory. Whether that is using a programming language I have never written in, or working in a field that I don’t know much about.
Rather than just declining these types of contracts and pigeon holing yourself into one area of practice, try giving the client a discount while you come up to speed. This benefits both you and the client. You, get on the job paid training to learn new concepts and expand your area of expertise, and the client gets their product built for a significantly lower cost.
Rates are a weird thing. I would encourage you to constantly experiment. Raise them, lower them, exchange some for equity. Find out what works for you and your clients.
Over at Pixegon, I really try to encourage my developers to have their own side projects. Often times, employers look at side projects as competition and try to own the works that their developers produce. Some will even go as far as to include this in their employee handbooks.
In my opinion, this stifles creativity and creates a feeling of contention between the employee and company.
People start side projects all of the time for a variety of reasons:
- To make some extra cash
- To learn a new technology
- To sharpen one’s skills
- Just for fun
From an employer’s standpoint, these are all great. It allows my developers the freedom to learn new things, make mistakes, and even earn extra cash. All without me fronting the cost.
While this might now sound selfish, it’s obviously a two-way street. Developers greatly benefit from this type of arrangement.
Getting started with a side project
This is one I struggle with all of the time. Sometimes it’s a motivation issue, sometimes I lack an idea, and sometimes I’m just feeling lazy and end up reading Hacker News instead due to my analysis paralysis.
The best bet is to just start. Whether your idea is big or small, stupid or world changing, just start writing some code. I try to utilize this tactic in all areas of my life from code, to writing, to working out, to minimizing, and even saving money. Once you get some momentum going, you will quickly find out what’s working and what’s not.
Here are a few Hacker News Posts that I found particularly inspiring to get you started:
Dont’ have any idea to start on? Try cloning something in one of the above posts. There are tons of ideas in here large and small and there’s plenty of room on the web for variances of differenct products. I probably stole most of this post from somewhere…
If you found this post helpful and want to hear more, make sure to subscribe to my newsletter. It’s not spammy, just let’s you know when I post.
Every single year since the beginning of time (at least since the beginning of this blog), I have resolved to “blog more”. And every single year, I have absolutely failed at that.
So, in favor of systems over resolutions, I am attempting to do something different this year. Over the holiday, I blogged 12 posts related to my experiences as an independent software developer as well as business owner that I feel could benefit the community. These share everything from selling contracts to hiring friends, mistakes made, and more.
I plan on releasing one post a month on the first Monday of every month. Given that I already have these posts written, it should be a no-brainer to blog consistently. I also intend on writing in-between posts, but at this point that’s probably wishful thinking.
If you have any interest in this sort of thing (software development consulting), then be sure to add yourself to the mailing list.
Wishing you a successful and exciting 2017.