There's a nice idiom, which is explained more in chapter 22 of Types and Programming Languages (it's used for polymorphism rather than dependent types, but the idea is the same). The idiom is as follows:
A type checking system can be turned into a type inference system by making the rules linear and adding constraints.
I'll use the application rule as an example. The checking rule in dependent types is this:
$$\frac{\Gamma \vdash t:\Pi x:A.B\quad \Gamma\vdash u:A}{\Gamma\vdash t\ u: B[u/x]} $$
Linearizing this rule requires re-naming the 2 occurrences of $A$, such that we obtain:
$$\frac{\Gamma \vdash t:\Pi x:A_1.B\quad \Gamma\vdash u:A_2}{\Gamma\vdash t\ u: B[u/x]} $$
But this isn't correct anymore! We need to add the constraint $A_1\simeq A_2$:
$$\frac{\Gamma \vdash t:\Pi x:A_1.B\quad \Gamma\vdash u:A_2}{\Gamma\vdash t\ u: B[u/x]}\quad A_1\simeq A_2 $$
Note that $\simeq$ denotes equivalence modulo your conversion relation ($\beta\eta$, typically), just like for the conversion rule, but it is now a unification constraint, since you may have meta-variables in your terms.
In the course of type checking, you'll accumulate constraints like these, to potentially solve them all at once at the end (or earlier for efficiency reasons).
Now things can get trickier, because the type of $t$ itself could be a metavariable in context! A more generally applicable rule would therefore be
$$\frac{\Gamma \vdash t:C\quad \Gamma\vdash u:A_2}{\Gamma\vdash t\ u: B[u/x]}\ C\simeq \Pi x:A_1.B,\ A_1\simeq A_2 $$
Or alternatively, keeping the previous rule and adding the rule
$$\frac{}{\Gamma_1, x:C, \Gamma_2 \vdash x: A} C\simeq A $$
at variable lookup time.
Another useful remark is that in the checking system, the conversion rule only needs to be applied right before applications, and possibly once at the very end of the derivation. Since this rules correspond to a unification constraint in the inference system, this tells you where to place the constraints.
